from:"Stephen Boyd"

Re: [PATCH V3 2/2] clk: vc5: Add support for optional load capacitance

2021-02-11 Thread Stephen Boyd

Quoting Adam Ford (2021-02-07 10:51:39)
> There are two registers which can set the load capacitance for
> XTAL1 and XTAL2. These are optional registers when using an
> external crystal.  Parse the device tree and set the
> corresponding registers accordingly.
> 
> Signed-off-by: Adam Ford 
> ---

Applied to clk-next

Re: [PATCH V3 1/2] dt-bindings: clk: versaclock5: Add optional load capacitance property

2021-02-11 Thread Stephen Boyd

Quoting Adam Ford (2021-02-07 10:51:38)
> There are two registers which can set the load capacitance for
> XTAL1 and XTAL2. These are optional registers when using an
> external crystal.  Since XTAL1 and XTAL2 will set to the same value,
> update the binding to support a single property called
> xtal-load-femtofarads.
> 
> Signed-off-by: Adam Ford 
> ---

Applied to clk-next

Re: [PATCH 21/21] clk: zynqmp: divider: Add missing description for 'max_div'

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:40)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/zynqmp/divider.c:46: warning: Function parameter or member 
> 'max_div' not described in 'zynqmp_clk_divider'
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Michal Simek 
> Cc: Rajan Vaja 
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 17/21] clk: clk-xgene: Add description for 'mask' and fix formatting for 'flags'

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:36)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/clk-xgene.c:229: warning: Function parameter or member 'mask' 
> not described in 'xgene_clk_pmd'
>  drivers/clk/clk-xgene.c:229: warning: Function parameter or member 'flags' 
> not described in 'xgene_clk_pmd'
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Loc Ho 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 19/21] clk: spear: Move prototype to accessible header

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:38)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/spear/spear1310_clock.c:385:13: warning: no previous prototype 
> for ‘spear1310_clk_init’ [-Wmissing-prototypes]
>  drivers/clk/spear/spear1340_clock.c:442:13: warning: no previous prototype 
> for ‘spear1340_clk_init’ [-Wmissing-prototypes]
> 
> Cc: Viresh Kumar 
> Cc: Shiraz Hashim 
> Cc: Russell King 
> Cc: Rajeev Kumar 
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 18/21] clk: qcom: clk-rpm: Remove a bunch of superfluous code

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:37)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/qcom/clk-rpm.c:453:29: warning: ‘clk_rpm_branch_ops’ defined but 
> not used [-Wunused-const-variable=]
> 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

This has been rejected before but OK

Applied to clk-next

Re: [PATCH 16/21] clk: qcom: mmcc-msm8974: Remove unused static const tables 'mmcc_xo_mmpll0_1_2_gpll0{map}'

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:35)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/qcom/mmcc-msm8974.c:85:27: warning: ‘mmcc_xo_mmpll0_1_2_gpll0’ 
> defined but not used [-Wunused-const-variable=]
>  drivers/clk/qcom/mmcc-msm8974.c:77:32: warning: 
> ‘mmcc_xo_mmpll0_1_2_gpll0_map’ defined but not used [-Wunused-const-variable=]
> 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 15/21] clk: clk-npcm7xx: Remove unused static const tables 'npcm7xx_gates' and 'npcm7xx_divs_fx'

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:34)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/clk-npcm7xx.c:438:43: warning: ‘npcm7xx_gates’ defined but not 
> used [-Wunused-const-variable=]
>  drivers/clk/clk-npcm7xx.c:365:48: warning: ‘npcm7xx_divs_fx’ defined but not 
> used [-Wunused-const-variable=]
> 
> Cc: Avi Fishman 
> Cc: Tomer Maimon 
> Cc: Tali Perry 
> Cc: Patrick Venture 
> Cc: Nancy Yuen 
> Cc: Benjamin Fair 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Nuvoton Technologies 
> Cc: open...@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 14/21] clk: clk-fixed-mmio: Demote obvious kernel-doc abuse

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:33)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/clk-fixed-mmio.c:62: warning: Function parameter or member 
> 'pdev' not described in 'of_fixed_mmio_clk_probe'
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Jan Kotas 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 10/21] clk: ti: dpll44xx: Fix some potential doc-rot

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:29)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/ti/dpll44xx.c:114: warning: Function parameter or member 'hw' 
> not described in 'omap4_dpll_regm4xen_recalc'
>  drivers/clk/ti/dpll44xx.c:114: warning: Function parameter or member 
> 'parent_rate' not described in 'omap4_dpll_regm4xen_recalc'
>  drivers/clk/ti/dpll44xx.c:114: warning: Excess function parameter 'clk' 
> description in 'omap4_dpll_regm4xen_recalc'
>  drivers/clk/ti/dpll44xx.c:150: warning: Function parameter or member 'hw' 
> not described in 'omap4_dpll_regm4xen_round_rate'
>  drivers/clk/ti/dpll44xx.c:150: warning: Function parameter or member 
> 'parent_rate' not described in 'omap4_dpll_regm4xen_round_rate'
>  drivers/clk/ti/dpll44xx.c:150: warning: Excess function parameter 'clk' 
> description in 'omap4_dpll_regm4xen_round_rate'
> 
> Cc: Tero Kristo 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: linux-o...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 13/21] clk: qcom: gcc-ipq4019: Remove unused variable 'ret'

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:32)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/qcom/gcc-ipq4019.c: In function ‘clk_cpu_div_set_rate’:
>  drivers/clk/qcom/gcc-ipq4019.c:1279:6: warning: variable ‘ret’ set but not 
> used [-Wunused-but-set-variable]
> 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 09/21] clk: tegra: cvb: Provide missing description for 'tegra_cvb_add_opp_table()'s align param

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:28)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/tegra/cvb.c:106: warning: Function parameter or member 'align' 
> not described in 'tegra_cvb_add_opp_table'
> 
> Cc: Peter De Schrijver 
> Cc: Prashant Gaikwad 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: linux-...@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 07/21] clk: tegra: clk-tegra30: Remove unused variable 'reg'

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:26)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/tegra/clk-tegra30.c: In function ‘tegra30_enable_cpu_clock’:
>  drivers/clk/tegra/clk-tegra30.c:1107:15: warning: variable ‘reg’ set but not 
> used [-Wunused-but-set-variable]
> 
> Cc: Peter De Schrijver 
> Cc: Prashant Gaikwad 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: linux-...@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 04/21] clk: qcom: clk-regmap: Provide missing description for 'devm_clk_register_regmap()'s dev param

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:23)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/qcom/clk-regmap.c:97: warning: Function parameter or member 
> 'dev' not described in 'devm_clk_register_regmap'
> 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 03/21] clk: ti: dpll3xxx: Fix some kernel-doc headers and promote other worthy ones

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:22)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/ti/dpll3xxx.c:414: warning: Function parameter or member 'hw' 
> not described in 'omap3_dpll_recalc'
>  drivers/clk/ti/dpll3xxx.c:414: warning: Function parameter or member 
> 'parent_rate' not described in 'omap3_dpll_recalc'
>  drivers/clk/ti/dpll3xxx.c:414: warning: Excess function parameter 'clk' 
> description in 'omap3_dpll_recalc'
>  drivers/clk/ti/dpll3xxx.c:437: warning: Function parameter or member 'hw' 
> not described in 'omap3_noncore_dpll_enable'
>  drivers/clk/ti/dpll3xxx.c:437: warning: Excess function parameter 'clk' 
> description in 'omap3_noncore_dpll_enable'
>  drivers/clk/ti/dpll3xxx.c:479: warning: Function parameter or member 'hw' 
> not described in 'omap3_noncore_dpll_disable'
>  drivers/clk/ti/dpll3xxx.c:479: warning: Excess function parameter 'clk' 
> description in 'omap3_noncore_dpll_disable'
>  drivers/clk/ti/dpll3xxx.c:755: warning: Function parameter or member 'hw' 
> not described in 'omap3_clkoutx2_recalc'
>  drivers/clk/ti/dpll3xxx.c:755: warning: Function parameter or member 
> 'parent_rate' not described in 'omap3_clkoutx2_recalc'
>  drivers/clk/ti/dpll3xxx.c:755: warning: Excess function parameter 'clk' 
> description in 'omap3_clkoutx2_recalc'
> 
> Cc: Tero Kristo 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: linux-o...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 02/21] clk: ti: clkt_dpll: Fix some kernel-doc misdemeanours

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:21)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/ti/clkt_dpll.c:284: warning: Function parameter or member 'hw' 
> not described in 'omap2_dpll_round_rate'
>  drivers/clk/ti/clkt_dpll.c:284: warning: Function parameter or member 
> 'parent_rate' not described in 'omap2_dpll_round_rate'
>  drivers/clk/ti/clkt_dpll.c:284: warning: Excess function parameter 'clk' 
> description in 'omap2_dpll_round_rate'
> 
> Cc: Tero Kristo 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Richard Woodruff 
> Cc: linux-o...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 01/21] clk: zynq: pll: Fix kernel-doc formatting in 'clk_register_zynq_pll's header

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:20)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/zynq/pll.c:187: warning: Function parameter or member 'name' not 
> described in 'clk_register_zynq_pll'
>  drivers/clk/zynq/pll.c:187: warning: Function parameter or member 'parent' 
> not described in 'clk_register_zynq_pll'
>  drivers/clk/zynq/pll.c:187: warning: Function parameter or member 'pll_ctrl' 
> not described in 'clk_register_zynq_pll'
>  drivers/clk/zynq/pll.c:187: warning: Function parameter or member 
> 'pll_status' not described in 'clk_register_zynq_pll'
>  drivers/clk/zynq/pll.c:187: warning: Function parameter or member 
> 'lock_index' not described in 'clk_register_zynq_pll'
>  drivers/clk/zynq/pll.c:187: warning: Function parameter or member 'lock' not 
> described in 'clk_register_zynq_pll'
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Michal Simek 
> Cc: "Sören Brinkmann" 
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 20/20] clk: zynq: clkc: Remove various instances of an unused variable 'clk'

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-20 01:30:40)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/zynq/clkc.c: In function ‘zynq_clk_register_fclk’:
>  drivers/clk/zynq/clkc.c:106:14: warning: variable ‘clk’ set but not used 
> [-Wunused-but-set-variable]
>  drivers/clk/zynq/clkc.c: In function ‘zynq_clk_register_periph_clk’:
>  drivers/clk/zynq/clkc.c:179:14: warning: variable ‘clk’ set but not used 
> [-Wunused-but-set-variable]
>  drivers/clk/zynq/clkc.c: In function ‘zynq_clk_setup’:
>  drivers/clk/zynq/clkc.c:220:14: warning: variable ‘clk’ set but not used 
> [-Wunused-but-set-variable]
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Michal Simek 
> Cc: "Sören Brinkmann" 
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 16/20] clk: ti: gate: Fix possible doc-rot in 'omap36xx_gate_clk_enable_with_hsdiv_restore'

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-20 01:30:36)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/ti/gate.c:67: warning: Function parameter or member 'hw' not 
> described in 'omap36xx_gate_clk_enable_with_hsdiv_restore'
>  drivers/clk/ti/gate.c:67: warning: Excess function parameter 'clk' 
> description in 'omap36xx_gate_clk_enable_with_hsdiv_restore'
> 
> Cc: Tero Kristo 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: linux-o...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 19/20] clk: versatile: clk-icst: Fix worthy struct documentation block

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-20 01:30:39)
> Also demote non-worthy header to standard comment block.
> 
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/versatile/clk-icst.c:53: warning: Function parameter or member 
> 'map' not described in 'clk_icst'
>  drivers/clk/versatile/clk-icst.c:53: warning: Function parameter or member 
> 'vcoreg_off' not described in 'clk_icst'
>  drivers/clk/versatile/clk-icst.c:53: warning: Function parameter or member 
> 'lockreg_off' not described in 'clk_icst'
>  drivers/clk/versatile/clk-icst.c:435: warning: cannot understand function 
> prototype: 'const struct icst_params icst525_apcp_cm_params = '
> 
> Cc: Linus Walleij 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 15/20] clk: ti: dpll: Fix misnaming of '_register_dpll()'s 'user' parameter

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-20 01:30:35)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/ti/dpll.c:163: warning: Function parameter or member 'user' not 
> described in '_register_dpll'
>  drivers/clk/ti/dpll.c:163: warning: Excess function parameter 'hw' 
> description in '_register_dpll'
> 
> Cc: Tero Kristo 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: linux-o...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 13/20] clk: ti: clockdomain: Fix description for 'omap2_init_clk_clkdm's hw param

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-20 01:30:33)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/ti/clockdomain.c:107: warning: Function parameter or member 'hw' 
> not described in 'omap2_init_clk_clkdm'
>  drivers/clk/ti/clockdomain.c:107: warning: Excess function parameter 'clk' 
> description in 'omap2_init_clk_clkdm'
> 
> Cc: Tero Kristo 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: linux-o...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 12/20] clk: st: clkgen-fsyn: Fix worthy struct documentation demote partially filled one

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-20 01:30:32)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/st/clkgen-fsyn.c:186: warning: Function parameter or member 
> 'data' not described in 'st_clk_quadfs_pll'
>  drivers/clk/st/clkgen-fsyn.c:466: warning: Function parameter or member 
> 'regs_base' not described in 'st_clk_quadfs_fsynth'
>  drivers/clk/st/clkgen-fsyn.c:466: warning: Function parameter or member 
> 'lock' not described in 'st_clk_quadfs_fsynth'
>  drivers/clk/st/clkgen-fsyn.c:466: warning: Function parameter or member 
> 'data' not described in 'st_clk_quadfs_fsynth'
>  drivers/clk/st/clkgen-fsyn.c:466: warning: Function parameter or member 
> 'chan' not described in 'st_clk_quadfs_fsynth'
>  drivers/clk/st/clkgen-fsyn.c:466: warning: Function parameter or member 'md' 
> not described in 'st_clk_quadfs_fsynth'
>  drivers/clk/st/clkgen-fsyn.c:466: warning: Function parameter or member 'pe' 
> not described in 'st_clk_quadfs_fsynth'
>  drivers/clk/st/clkgen-fsyn.c:466: warning: Function parameter or member 
> 'sdiv' not described in 'st_clk_quadfs_fsynth'
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Kees Cook 
> Cc: Stephen Gallimore 
> Cc: Pankaj Dev 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 11/20] clk: st: clkgen-pll: Demote unpopulated kernel-doc header

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-20 01:30:31)
> And remove an incorrect entry.
> 
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/st/clkgen-pll.c:142: warning: cannot understand function 
> prototype: 'struct clkgen_pll '
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Stephen Gallimore 
> Cc: Pankaj Dev 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 09/20] clk: mvebu: ap-cpu-clk: Demote non-conformant kernel-doc header

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-20 01:30:29)
> Not much effort has been put into this one.
> 
> Demote it for the time being at least.
> 
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/mvebu/ap-cpu-clk.c:52: warning: Function parameter or member 
> 'ratio_state_reg' not described in 'cpu_dfs_regs'
>  drivers/clk/mvebu/ap-cpu-clk.c:52: warning: Function parameter or member 
> 'divider_mask' not described in 'cpu_dfs_regs'
>  drivers/clk/mvebu/ap-cpu-clk.c:52: warning: Function parameter or member 
> 'cluster_offset' not described in 'cpu_dfs_regs'
>  drivers/clk/mvebu/ap-cpu-clk.c:52: warning: Function parameter or member 
> 'force_mask' not described in 'cpu_dfs_regs'
>  drivers/clk/mvebu/ap-cpu-clk.c:52: warning: Function parameter or member 
> 'divider_offset' not described in 'cpu_dfs_regs'
>  drivers/clk/mvebu/ap-cpu-clk.c:52: warning: Function parameter or member 
> 'divider_ratio' not described in 'cpu_dfs_regs'
>  drivers/clk/mvebu/ap-cpu-clk.c:52: warning: Function parameter or member 
> 'ratio_offset' not described in 'cpu_dfs_regs'
>  drivers/clk/mvebu/ap-cpu-clk.c:52: warning: Function parameter or member 
> 'ratio_state_offset' not described in 'cpu_dfs_regs'
>  drivers/clk/mvebu/ap-cpu-clk.c:52: warning: Function parameter or member 
> 'ratio_state_cluster_offset' not described in 'cpu_dfs_regs'
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Julia Lawall 
> Cc: Omri Itach 
> Cc: Gregory Clement 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 08/20] clk: socfpga: clk-pll-a10: Remove set but unused variable 'rc'

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-20 01:30:28)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/socfpga/clk-pll-a10.c: In function ‘__socfpga_pll_init’:
>  drivers/clk/socfpga/clk-pll-a10.c:76:6: warning: variable ‘rc’ set but not 
> used [-Wunused-but-set-variable]
> 
> Cc: Dinh Nguyen 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 07/20] clk: socfpga: clk-pll: Remove unused variable 'rc'

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-20 01:30:27)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/socfpga/clk-pll.c: In function ‘__socfpga_pll_init’:
>  drivers/clk/socfpga/clk-pll.c:83:6: warning: variable ‘rc’ set but not used 
> [-Wunused-but-set-variable]
> 
> Cc: Dinh Nguyen 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 06/20] clk: sifive: fu540-prci: Declare static const variable 'prci_clk_fu540' where it's used

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-20 01:30:26)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/sifive/fu540-prci.h:16:35: warning: ‘prci_clk_fu540’ defined but 
> not used [-Wunused-const-variable=]
>  drivers/clk/sifive/fu540-prci.h:16:35: warning: ‘prci_clk_fu540’ defined but 
> not used [-Wunused-const-variable=]
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Paul Walmsley 
> Cc: Palmer Dabbelt 
> Cc: Pragnesh Patel 
> Cc: Zong Li 
> Cc: linux-...@vger.kernel.org
> Cc: linux-ri...@lists.infradead.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 05/20] clk: bcm: clk-iproc-pll: Demote kernel-doc abuse

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-20 01:30:25)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/bcm/clk-iproc-pll.c:712: warning: Function parameter or member 
> 'pll' not described in 'iproc_pll_sw_cfg'
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Ray Jui 
> Cc: Scott Branden 
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones 
> ---

Applied to clk-next

Re: [PATCH 08/21] clk: clkdev: Ignore suggestion to use gnu_printf() as it's not appropriate here

2021-02-11 Thread Stephen Boyd

Quoting Lee Jones (2021-01-26 04:45:27)
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/clk/clkdev.c: In function ‘vclkdev_alloc’:
>  drivers/clk/clkdev.c:173:3: warning: function ‘vclkdev_alloc’ might be a 
> candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
> 
> Cc: Russell King 
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/clk/clkdev.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> index 0f2e3fcf0f19f..5e5f25d568724 100644
> --- a/drivers/clk/clkdev.c
> +++ b/drivers/clk/clkdev.c
> @@ -153,6 +153,11 @@ struct clk_lookup_alloc {
> charcon_id[MAX_CON_ID];
>  };
>  
> +#pragma GCC diagnostic push
> +#ifndef __clang__
> +#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
> +#endif

Can this be some macro banished to compiler.h?

> +
>  static struct clk_lookup * __ref
>  vclkdev_alloc(struct clk_hw *hw, const char *con_id, const char *dev_fmt,
> va_list ap)
> @@ -177,6 +182,8 @@ vclkdev_alloc(struct clk_hw *hw, const char *con_id, 
> const char *dev_fmt,
> return >cl;
>  }
>  
> +#pragma GCC diagnostic pop
> +
>  static struct clk_lookup *
>  vclkdev_create(struct clk_hw *hw, const char *con_id, const char *dev_fmt,
> va_list ap)
> -- 
> 2.25.1
>

Re: [PATCH V2] opp: Don't ignore clk_get() errors other than -ENOENT

2021-02-11 Thread Stephen Boyd

Quoting Viresh Kumar (2021-01-31 20:22:58)
> Not all devices that need to use OPP core need to have clocks, a missing
> clock is fine in which case -ENOENT shall be returned by clk_get().
> 
> Anything else is an error and must be handled properly.
> 
> Reported-by: Dmitry Osipenko 
> Signed-off-by: Viresh Kumar 
> ---
> V2:
> - s/ENODEV/ENOENT
> - Use dev_err_probe()
> 
> Stephen, is the understanding correct that -ENOENT is the only error
> returned for missing clocks ?

Yeah pretty much. See clk_get_optional().

Re: [PATCH v5 3/4] usb: host: xhci-plat: Create platform device for onboard hubs in probe()

2021-02-11 Thread Stephen Boyd

Quoting Matthias Kaehlcke (2021-02-10 14:20:18)
> 
> On Wed, Feb 10, 2021 at 10:06:45PM +0100, Krzysztof Kozlowski wrote:
> > 
> > This looks hackish... what if later we have something else than hub?
> > Another if()?
> > 
> > What if hub could be connected to something else than XHCI controller?
> 
> In earlier versions this was standalone driver, which was more flexible and
> didn't require cooperation from the XHCI driver:
> 
> https://lore.kernel.org/patchwork/patch/1313001/
> 
> Rob Herring raised objections about the DT bindings, since the USB hub would 
> be
> represented twice in the DT, once in the USB hierachry (with an explicit node 
> or
> implicitly) plus a node for the platform device for the new driver:
> 
> https://lore.kernel.org/patchwork/patch/1305395/
> https://lore.kernel.org/patchwork/patch/1313000/
> 
> Alan Stern suggested to create the platform device in the XHCI platform 
> driver:
> 
> https://lore.kernel.org/patchwork/patch/1313000/#1510227
> 
> I wasn't super happy about involving xhci-plat, but at least the code is 
> minimal
> and all the device specific stuff is handled by the onboard_usb_hub driver.
> 
> If you have better suggestions that might satisfy all parties please let us
> know :)
> 

Is it possible to use the graph binding to connect the USB controller on
the SoC to the port on the hub? Then the hub would be a standalone node
at the root of DT connected to the USB controller (or phy) and xhci code
could probe the firmware to see if there's a graph connection downstream
that is a powered hub like this. I didn't see this idea mentioned in the
previous discussions, but maybe I missed it.

Re: [PATCH][next] soc: xilinx: vcu: remove deadcode on null divider check

2021-02-11 Thread Stephen Boyd

Quoting Michael Tretter (2021-02-10 23:39:06)
> On Wed, 10 Feb 2021 19:28:18 -0800, Stephen Boyd wrote:
> > Quoting Colin King (2021-02-10 10:49:38)
> > > From: Colin Ian King 
> > > 
> > > The pointer 'divider' has previously been null checked followed by
> > > a return, hence the subsequent null check is redundant deadcode
> > > that can be removed.  Clean up the code and remove it.
> > > 
> > > Fixes: 9c789deea206 ("soc: xilinx: vcu: implement clock provider for 
> > > output clocks")
> > > Signed-off-by: Colin Ian King 
> > > ---
> > >  drivers/clk/xilinx/xlnx_vcu.c | 3 ---
> > >  1 file changed, 3 deletions(-)
> > > 
> > > diff --git a/drivers/clk/xilinx/xlnx_vcu.c b/drivers/clk/xilinx/xlnx_vcu.c
> > > index d66b1315114e..607936d7a413 100644
> > > --- a/drivers/clk/xilinx/xlnx_vcu.c
> > > +++ b/drivers/clk/xilinx/xlnx_vcu.c
> > > @@ -512,9 +512,6 @@ static void xvcu_clk_hw_unregister_leaf(struct clk_hw 
> > > *hw)
> > >  
> > > mux = clk_hw_get_parent(divider);
> > > clk_hw_unregister_mux(mux);
> > > -   if (!divider)
> > > -   return;
> > > -
> > 
> > This code is pretty confusing. Waiting for m.tret...@pengutronix.de to
> > reply
> 
> Can you elaborate what you find confusing about this code. I would gladly try
> to clarify and improve the code.

The fact that pointers are being checked and then bailing out of the
function early, vs. doing something if the pointer is non-NULL.

> 
> What happens here is that the driver registers a mux -> divider -> gate chain
> for each output clock, but only stores the gate clock. When unregistering the
> clocks, the driver starts at the gate and walks up to the mux while
> unregistering the clocks.
>

Re: [PATCH] lkdtm: don't move ctors to .rodata

2021-02-11 Thread Stephen Boyd

Quoting Greg Kroah-Hartman (2021-02-11 06:23:10)
> On Wed, Feb 10, 2021 at 04:36:08PM -0800, Stephen Boyd wrote:
> > Quoting Greg Kroah-Hartman (2020-12-09 06:51:33)
> > > On Tue, Dec 08, 2020 at 01:20:56PM -0800, Kees Cook wrote:
> > > > On Mon, Dec 07, 2020 at 05:05:33PM +, Mark Rutland wrote:
> > > > > [0.969110] Code: 0003    ()
> > > > > [0.970815] ---[ end trace b5339784e20d015c ]---
> > > > > 
> > > > > Signed-off-by: Mark Rutland 
> > > > 
> > > > Oh, eek. Why was a ctor generated at all? But yes, this looks good.
> > > > Greg, can you pick this up please?
> > > > 
> > > > Acked-by: Kees Cook 
> > > 
> > > Now picked up, thanks.
> > > 
> > 
> > Can this be backported to 5.4 and 5.10 stable trees? I just ran across
> > this trying to use kasan on 5.4 with lkdtm and it blows up early. This
> > patch applies on 5.4 cleanly but doesn't compile because it's missing
> > noinstr. Here's a version of the patch that introduces noinstr on 5.4.97
> > so this patch can be picked to 5.4 stable trees.
> 
> Why 5.10?  This showed up in 5.8, so how would it be needed there?
> 

Sorry for the confusion. Can commit 65538943 ("vmlinux.lds.h: Create
section for protection against instrumentation") and commit 3f618ab33234
("lkdtm: don't move ctors to .rodata") be backported to 5.4.y and only
commit 3f618ab3323407ee4c6a6734a37eb6e9663ebfb9 be backported to 5.10.y?

Re: [PATCH][next] soc: xilinx: vcu: remove deadcode on null divider check

2021-02-10 Thread Stephen Boyd

Quoting Colin King (2021-02-10 10:49:38)
> From: Colin Ian King 
> 
> The pointer 'divider' has previously been null checked followed by
> a return, hence the subsequent null check is redundant deadcode
> that can be removed.  Clean up the code and remove it.
> 
> Fixes: 9c789deea206 ("soc: xilinx: vcu: implement clock provider for output 
> clocks")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/clk/xilinx/xlnx_vcu.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/clk/xilinx/xlnx_vcu.c b/drivers/clk/xilinx/xlnx_vcu.c
> index d66b1315114e..607936d7a413 100644
> --- a/drivers/clk/xilinx/xlnx_vcu.c
> +++ b/drivers/clk/xilinx/xlnx_vcu.c
> @@ -512,9 +512,6 @@ static void xvcu_clk_hw_unregister_leaf(struct clk_hw *hw)
>  
> mux = clk_hw_get_parent(divider);
> clk_hw_unregister_mux(mux);
> -   if (!divider)
> -   return;
> -

This code is pretty confusing. Waiting for m.tret...@pengutronix.de to
reply

> clk_hw_unregister_divider(divider);
>  }
>

Re: [RFC v1] clk: core: support clocks that need to be enabled during re-parent

2021-02-10 Thread Stephen Boyd

Quoting Laurent Pinchart (2021-01-23 10:42:27)
> Hi Stephen,
> 
> On Tue, Jun 25, 2019 at 08:52:45PM -0700, Stephen Boyd wrote:
> > Quoting Weiyi Lu (2019-06-25 18:05:22)
> > > On Tue, 2019-06-25 at 15:14 -0700, Stephen Boyd wrote:
> > > > Quoting Weiyi Lu (2019-06-09 20:44:53)
> > > > > When using property assigned-clock-parents to assign parent clocks,
> > > > > core clocks might still be disabled during re-parent.
> > > > > Add flag 'CLK_OPS_CORE_ENABLE' for those clocks must be enabled
> > > > > during re-parent.
> > > > > 
> > > > > Signed-off-by: Weiyi Lu 
> > > > 
> > > > Can you further describe the scenario where this is a problem? Is it
> > > > some sort of clk that is enabled by default out of the bootloader and is
> > > > then configured to have an 'assigned-clock-parents' property to change
> > > > the parent, but that clk needs to be "enabled" so that the framework
> > > > turns on the parents for the parent switch?
> > > 
> > > When driver is built as module(.ko) and install at runtime after the
> > > whole initialization stage. Clk might already be turned off before
> > > configuring by assigned-clock-parents. For such clock design that need
> > > to have clock enabled during re-parent, the configuration of
> > > assigned-clock-parents might be failed. That's the problem we have now.
> > 
> > Great. Please put this sort of information in the commit text.
> > 
> > > Do you have any suggestion for such usage of clocks? Many thanks.
> > 
> > Ok, and in this case somehow CLK_OPS_PARENT_ENABLE flag doesn't work? Is
> > that because the clk itself doesn't do anything unless it's enabled?  I
> > seem to recall that we usually work around this by caching the state of
> > the clk parents or frequencies and then when the clk prepare or enable
> > op is called we actually write the hardware to change the state. There
> > are some qcom clks like this and we basically just use the hardware
> > itself to cache the state of the clk while it hasn't actually changed to
> > be at that rate, because the clk is not enabled yet.
> 
> I'm trying to move the fix to the clock driver itself. Do you have any
> pointer to such a clock that I can use as an example ?

This reminds me of some stuff we did in the qcom clk driver to handle
shared clks. Look at clk_rcg2_shared_ops in drivers/clk/qcom/clk-rcg2.c
for some more details. But there we have hardware that allows you to
write new settings but not set the "go" bit that actually switches the
mux/divider to a new rate. The non-linux entity using the clks doesn't
care what rate the clk is running at, it needs to just make sure the clk
turns on so it can do its thing. But the problem is the clk can be
turned on and off at random and that gets the clk stuck, so we put the
clk at some safe frequency that is always on (XO) and let the other side
go wild. But to the kernel we want it to think the rate is still what it
was set to, so we cache away the rate the kernel thinks in the hardware
and don't set the "go" bit so that when we enable the clk again in linux
it will reconfigure the clk to be the rate we want.

If you don't have that hardware then I suppose you'll have to cache the
register value in the set_rate clk op and return that cached value from
recalc_rate but only write the register value on the prepare/enable
path. Should be doable, but not a lot of fun! It may also be possible to
have some clk flag that makes the core do this for you by calling the
set_rate() call at the right time.

> 
> > The main concern is that we're having to turn on clks to make things
> > work, when it would be best to not turn on clks just so that register
> > writes actually make a difference to what the hardware does.
> 
> I agree, it's best not to turn the clock on if we can avoid it.
>

Re: [PATCH v6 02/15] clk: tegra: Don't enable PLLE HW sequencer at init

2021-02-10 Thread Stephen Boyd

Quoting JC Kuo (2021-01-19 00:55:33)
> PLLE hardware power sequencer references PEX/SATA UPHY PLL hardware
> power sequencers' output to enable/disable PLLE. PLLE hardware power
> sequencer has to be enabled only after PEX/SATA UPHY PLL's sequencers
> are enabled.
> 
> Signed-off-by: JC Kuo 
> Acked-by: Thierry Reding 
> ---

Acked-by: Stephen Boyd

Re: [PATCH v6 01/15] clk: tegra: Add PLLE HW power sequencer control

2021-02-10 Thread Stephen Boyd

Quoting JC Kuo (2021-01-19 00:55:32)
> PLLE has a hardware power sequencer logic which is a state machine
> that can power on/off PLLE without any software intervention. The
> sequencer has two inputs, one from XUSB UPHY PLL and the other from
> SATA UPHY PLL. PLLE provides reference clock to XUSB and SATA UPHY
> PLLs. When both of the downstream PLLs are powered-off, PLLE hardware
> power sequencer will automatically power off PLLE for power saving.
> 
> XUSB and SATA UPHY PLLs also have their own hardware power sequencer
> logic. XUSB UPHY PLL is shared between XUSB SuperSpeed ports and PCIE
> controllers. The XUSB UPHY PLL hardware power sequencer has inputs
> from XUSB and PCIE. When all of the XUSB SuperSpeed ports and PCIE
> controllers are in low power state, XUSB UPHY PLL hardware power
> sequencer automatically power off PLL and flags idle to PLLE hardware
> power sequencer. Similar applies to SATA UPHY PLL.
> 
> PLLE hardware power sequencer has to be enabled after both downstream
> sequencers are enabled.
> 
> This commit adds two helper functions:
> 1. tegra210_plle_hw_sequence_start() for XUSB PADCTL driver to enable
>PLLE hardware sequencer at proper time.
> 
> 2. tegra210_plle_hw_sequence_is_enabled() for XUSB PADCTL driver to
>check whether PLLE hardware sequencer has been enabled or not.
> 
> Signed-off-by: JC Kuo 
> Acked-by: Thierry Reding 
> ---

Acked-by: Stephen Boyd

Re: [PATCH] clk: socfpga: agilex: add clock driver for eASIC N5X platform

2021-02-10 Thread Stephen Boyd

Quoting Dinh Nguyen (2021-01-05 11:29:56)
> Add support for Intel's eASIC N5X platform. The clock manager driver for
> the N5X is very similar to the Agilex platform, we can re-use most of
> the Agilex clock driver.
> 
> This patch makes the necessary changes for the driver to differentiate
> between the Agilex and the N5X platforms.
> 
> Signed-off-by: Dinh Nguyen 
> ---

Sorry this patch fell off my radar.

I ran checkpatch

WARNING: function definition argument 'struct platform_device *' should also 
have an identifier name
#135: FILE: drivers/clk/socfpga/clk-agilex.c:500:
+   int (*probe_func)(struct platform_device *);

WARNING: Statements terminations use 1 semicolon
#140: FILE: drivers/clk/socfpga/clk-agilex.c:505:
+   return  probe_func(pdev);;

WARNING: DT compatible string "intel,n5x-clkmgr" appears un-documented -- check 
./Documentation/devicetree/bindings/
#147: FILE: drivers/clk/socfpga/clk-agilex.c:511:
+   { .compatible = "intel,n5x-clkmgr",

WARNING: struct clk_ops should normally be const
#290: FILE: drivers/clk/socfpga/clk-pll-s10.c:166:
+static struct clk_ops n5x_clk_pll_ops = {

WARNING: struct clk_ops should normally be const
#296: FILE: drivers/clk/socfpga/clk-pll-s10.c:172:
+static struct clk_ops agilex_clk_pll_ops = {

WARNING: function definition argument 'const struct stratix10_pll_clock *' 
should also have an identifier name
#367: FILE: drivers/clk/socfpga/stratix10-clk.h:78:
+struct clk *n5x_register_pll(const struct stratix10_pll_clock *,

WARNING: function definition argument 'void __iomem *' should also have an 
identifier name
#367: FILE: drivers/clk/socfpga/stratix10-clk.h:78:
+struct clk *n5x_register_pll(const struct stratix10_pll_clock *,

WARNING: function definition argument 'const struct n5x_perip_c_clock *' should 
also have an identifier name
#371: FILE: drivers/clk/socfpga/stratix10-clk.h:82:
+struct clk *n5x_register_periph(const struct n5x_perip_c_clock *,

WARNING: function definition argument 'void __iomem *' should also have an 
identifier name
#371: FILE: drivers/clk/socfpga/stratix10-clk.h:82:
+struct clk *n5x_register_periph(const struct n5x_perip_c_clock *,

Can you fix these up and resend?

>  drivers/clk/socfpga/clk-agilex.c | 88 +++-
>  drivers/clk/socfpga/clk-periph-s10.c | 53 +
>  drivers/clk/socfpga/clk-pll-s10.c| 85 ++-
>  drivers/clk/socfpga/stratix10-clk.h  | 15 +
>  4 files changed, 238 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/socfpga/clk-periph-s10.c 
> b/drivers/clk/socfpga/clk-periph-s10.c
> index 397b77b89b16..135581c41c05 100644
> --- a/drivers/clk/socfpga/clk-periph-s10.c
> +++ b/drivers/clk/socfpga/clk-periph-s10.c
> @@ -15,6 +15,21 @@
>  
>  #define to_periph_clk(p) container_of(p, struct socfpga_periph_clk, hw.hw)
>  
> +static unsigned long n5x_clk_peri_c_clk_recalc_rate(struct clk_hw *hwclk,
> +unsigned long parent_rate)
> +{
> +   struct socfpga_periph_clk *socfpgaclk = to_periph_clk(hwclk);
> +   unsigned long div;
> +   unsigned long shift = socfpgaclk->shift;
> +   u32 val;
> +
> +   val = readl(socfpgaclk->hw.reg);
> +   val &= (0x1F << shift);

Prefer lowercase hex.

> +   div = (val >> shift) + 1;
> +
> +   return parent_rate / div;
> +}
> +
>  static unsigned long clk_peri_c_clk_recalc_rate(struct clk_hw *hwclk,
>  unsigned long parent_rate)
>  {
> @@ -63,6 +78,11 @@ static u8 clk_periclk_get_parent(struct clk_hw *hwclk)
> return parent;
>  }
>  
> +static const struct clk_ops n5x_peri_c_clk_ops = {
> +   .recalc_rate = n5x_clk_peri_c_clk_recalc_rate,
> +   .get_parent = clk_periclk_get_parent,
> +};
> +
>  static const struct clk_ops peri_c_clk_ops = {
> .recalc_rate = clk_peri_c_clk_recalc_rate,
> .get_parent = clk_periclk_get_parent,
> @@ -107,6 +127,39 @@ struct clk *s10_register_periph(const struct 
> stratix10_perip_c_clock *clks,
> return clk;
>  }
>  
> +struct clk *n5x_register_periph(const struct n5x_perip_c_clock *clks,
> +   void __iomem *regbase)
> +{
> +   struct clk *clk;
> +   struct socfpga_periph_clk *periph_clk;
> +   struct clk_init_data init;
> +   const char *name = clks->name;
> +   const char *parent_name = clks->parent_name;
> +
> +   periph_clk = kzalloc(sizeof(*periph_clk), GFP_KERNEL);
> +   if (WARN_ON(!periph_clk))
> +   return NULL;
> +
> +   periph_clk->hw.reg = regbase + clks->offset;
> +   periph_clk->shift = clks->shift;
> +
> +   init.name = name;
> +   init.ops = _peri_c_clk_ops;
> +   init.flags = clks->flags;
> +
> +   init.num_parents = clks->num_parents;
> +   init.parent_names = parent_name ? _name : NULL;
> +
> +   periph_clk->hw.hw.init = 
> +
> +   clk = clk_register(NULL, _clk->hw.hw);

Can you use clk_hw_register?

Re: [PATCH 2/6] dt-bindings: clk: mstar msc313 mpll binding description

2021-02-10 Thread Stephen Boyd

Quoting Daniel Palmer (2021-02-10 18:28:40)
> Hi Stephen,
> 
> On Wed, 10 Feb 2021 at 11:29, Stephen Boyd  wrote:
> > The child clks should be using clk_parent_data to point to the parent
> > clks through DT. That way the name of the clk doesn't matter except for
> > debug purposes.
> 
> I think I get it now. I was using of_clk_parent_fill() to get the
> parent clocks sourced
> from the mpll but I seems like I should be filling out an array of
> struct clk_parent_data
> with the indices of the parents and using
> clk_register_composite_pdata() etc instead.
> 

Yes that's the idea. Thanks!

[PATCH v6 3/3] iio: proximity: Add a ChromeOS EC MKBP proximity driver

2021-02-10 Thread Stephen Boyd

Add support for a ChromeOS EC proximity driver that exposes a "front"
proximity sensor via the IIO subsystem. The EC decides when front
proximity is near and sets an MKBP switch 'EC_MKBP_FRONT_PROXIMITY' to
notify the kernel of proximity. Similarly, when proximity detects
something far away it sets the switch bit to 0. For now this driver
exposes a single sensor, but it could be expanded in the future via more
MKBP bits if desired.

Cc: Dmitry Torokhov 
Cc: Benson Leung 
Cc: Guenter Roeck 
Cc: Douglas Anderson 
Cc: Gwendal Grignou 
Reviewed-by: Enric Balletbo i Serra 
Signed-off-by: Stephen Boyd 
---

Changes from v5:
 * Only push event if it's different
 * Check switch on resume

 drivers/iio/proximity/Kconfig |  11 +
 drivers/iio/proximity/Makefile|   1 +
 .../iio/proximity/cros_ec_mkbp_proximity.c| 271 ++
 3 files changed, 283 insertions(+)
 create mode 100644 drivers/iio/proximity/cros_ec_mkbp_proximity.c

diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
index 12672a0e89ed..7c7203ca3ac6 100644
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -21,6 +21,17 @@ endmenu
 
 menu "Proximity and distance sensors"
 
+config CROS_EC_MKBP_PROXIMITY
+   tristate "ChromeOS EC MKBP Proximity sensor"
+   depends on CROS_EC
+   help
+ Say Y here to enable the proximity sensor implemented via the 
ChromeOS EC MKBP
+ switches protocol. You must enable one bus option (CROS_EC_I2C or 
CROS_EC_SPI)
+ to use this.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cros_ec_mkbp_proximity.
+
 config ISL29501
tristate "Intersil ISL29501 Time Of Flight sensor"
depends on I2C
diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
index 9c1aca1a8b79..cbdac09433eb 100644
--- a/drivers/iio/proximity/Makefile
+++ b/drivers/iio/proximity/Makefile
@@ -5,6 +5,7 @@
 
 # When adding new entries keep the list in alphabetical order
 obj-$(CONFIG_AS3935)   += as3935.o
+obj-$(CONFIG_CROS_EC_MKBP_PROXIMITY) += cros_ec_mkbp_proximity.o
 obj-$(CONFIG_ISL29501) += isl29501.o
 obj-$(CONFIG_LIDAR_LITE_V2)+= pulsedlight-lidar-lite-v2.o
 obj-$(CONFIG_MB1232)   += mb1232.o
diff --git a/drivers/iio/proximity/cros_ec_mkbp_proximity.c 
b/drivers/iio/proximity/cros_ec_mkbp_proximity.c
new file mode 100644
index ..8213b0081713
--- /dev/null
+++ b/drivers/iio/proximity/cros_ec_mkbp_proximity.c
@@ -0,0 +1,271 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for cros-ec proximity sensor exposed through MKBP switch
+ *
+ * Copyright 2021 Google LLC.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+struct cros_ec_mkbp_proximity_data {
+   struct cros_ec_device *ec;
+   struct iio_dev *indio_dev;
+   struct mutex lock;
+   struct notifier_block notifier;
+   int last_proximity;
+   bool enabled;
+};
+
+static const struct iio_event_spec cros_ec_mkbp_proximity_events[] = {
+   {
+   .type = IIO_EV_TYPE_THRESH,
+   .dir = IIO_EV_DIR_EITHER,
+   .mask_separate = BIT(IIO_EV_INFO_ENABLE),
+   },
+};
+
+static const struct iio_chan_spec cros_ec_mkbp_proximity_chan_spec[] = {
+   {
+   .type = IIO_PROXIMITY,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+   .event_spec = cros_ec_mkbp_proximity_events,
+   .num_event_specs = ARRAY_SIZE(cros_ec_mkbp_proximity_events),
+   },
+};
+
+static int cros_ec_mkbp_proximity_parse_state(const void *data)
+{
+   u32 switches = get_unaligned_le32(data);
+
+   return !!(switches & BIT(EC_MKBP_FRONT_PROXIMITY));
+}
+
+static int cros_ec_mkbp_proximity_query(struct cros_ec_device *ec_dev,
+   int *state)
+{
+   struct {
+   struct cros_ec_command msg;
+   union {
+   struct ec_params_mkbp_info params;
+   u32 switches;
+   };
+   } __packed buf = { };
+   struct ec_params_mkbp_info *params = 
+   struct cros_ec_command *msg = 
+   u32 *switches = 
+   size_t insize = sizeof(*switches);
+   int ret;
+
+   msg->command = EC_CMD_MKBP_INFO;
+   msg->version = 1;
+   msg->outsize = sizeof(*params);
+   msg->insize = insize;
+
+   params->info_type = EC_MKBP_INFO_CURRENT;
+   params->event_type = EC_MKBP_EVENT_SWITCH;
+
+   ret = cros_ec_cmd_xfer_status(ec_dev, msg);
+   if (ret < 0)
+   return ret;
+
+   if (ret != insize) {
+   dev_warn(ec_dev->dev, "wrong result size: %d != %zu\n", ret,
+insize);
+   r

[PATCH v6 2/3] dt-bindings: iio: Add cros ec proximity yaml doc

2021-02-10 Thread Stephen Boyd

Some cros ECs support a front proximity MKBP event via
'EC_MKBP_FRONT_PROXIMITY'. Add a DT binding to document this feature via
a node that is a child of the main cros_ec device node. Devices that
have this ability will describe this in firmware.

Cc: Dmitry Torokhov 
Cc: Benson Leung 
Cc: Guenter Roeck 
Cc: Douglas Anderson 
Cc: Gwendal Grignou 
Cc: 
Reviewed-by: Rob Herring 
Cc: Enric Balletbo i Serra 
Signed-off-by: Stephen Boyd 
---
 .../google,cros-ec-mkbp-proximity.yaml| 37 +++
 .../bindings/mfd/google,cros-ec.yaml  |  7 
 2 files changed, 44 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml

diff --git 
a/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
 
b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
new file mode 100644
index ..099b4be927d4
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: 
http://devicetree.org/schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ChromeOS EC MKBP Proximity Sensor
+
+maintainers:
+  - Stephen Boyd 
+  - Benson Leung 
+  - Enric Balletbo i Serra 
+
+description: |
+  Google's ChromeOS EC sometimes has the ability to detect user proximity.
+  This is implemented on the EC as near/far logic and exposed to the OS
+  via an MKBP switch bit.
+
+properties:
+  compatible:
+const: google,cros-ec-mkbp-proximity
+
+  label:
+description: Name for proximity sensor
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+proximity {
+  compatible = "google,cros-ec-mkbp-proximity";
+  label = "proximity-wifi-lte";
+};
diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml 
b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
index 76bf16ee27ec..4dfa70a013ae 100644
--- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
+++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
@@ -94,6 +94,9 @@ properties:
   keyboard-controller:
 $ref: "/schemas/input/google,cros-ec-keyb.yaml#"
 
+  proximity:
+$ref: "/schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#"
+
   codecs:
 type: object
 additionalProperties: false
@@ -180,6 +183,10 @@ examples:
 interrupts = <99 0>;
 interrupt-parent = <>;
 spi-max-frequency = <500>;
+
+proximity {
+compatible = "google,cros-ec-mkbp-proximity";
+};
 };
 };
 
-- 
https://chromeos.dev

[PATCH v6 1/3] platform/chrome: cros_ec: Add SW_FRONT_PROXIMITY MKBP define

2021-02-10 Thread Stephen Boyd

Some cros ECs support a front proximity MKBP event via
'EC_MKBP_FRONT_PROXIMITY'. Add this define so it can be used in a
future patch.

Cc: Dmitry Torokhov 
Cc: Benson Leung 
Cc: Guenter Roeck 
Cc: Douglas Anderson 
Cc: Gwendal Grignou 
Acked-by: Enric Balletbo i Serra 
Signed-off-by: Stephen Boyd 
---
 include/linux/platform_data/cros_ec_commands.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/platform_data/cros_ec_commands.h 
b/include/linux/platform_data/cros_ec_commands.h
index 86376779ab31..776e0b2be0e9 100644
--- a/include/linux/platform_data/cros_ec_commands.h
+++ b/include/linux/platform_data/cros_ec_commands.h
@@ -3457,6 +3457,7 @@ struct ec_response_get_next_event_v1 {
 #define EC_MKBP_LID_OPEN   0
 #define EC_MKBP_TABLET_MODE1
 #define EC_MKBP_BASE_ATTACHED  2
+#define EC_MKBP_FRONT_PROXIMITY3
 
 /* Run keyboard factory test scanning */
 #define EC_CMD_KEYBOARD_FACTORY_TEST 0x0068
-- 
https://chromeos.dev

[PATCH v6 0/3] iio: Add a ChromeOS EC MKBP proximity driver

2021-02-10 Thread Stephen Boyd

This is a different approach to [1] where I tried to add this proximity
sensor logic to the input subsystem. Instead, we'll take the approach of
making a small IIO proximity driver that parses the EC switch bitmap to
find out if the front proximity sensor is detecting something or not.
This allows us to treat proximity sensors as IIO devices all the time in
userspace instead of handling this switch on the EC via the input
subsystem and then other proximity sensors via IIO.

I propose this is all merged through IIO subsystem. Please ack
the first patch so it can be merged that way.

Changes from v5:
 * Picked up RB tag from Rob
 * Track state of switch and only push event if it's different

Changes from v4:
 * Reduced binding and moved proximity node to mfd spi example
 * Dropped of_match_ptr()

Changes from v3:
 * Added SPI and cros-ec wrapper nodes to yaml example
 * Ignore notifier registration return code that is always zero

Changes from v2:
 * Check iio clock and use IIO time if not boottime

Changes from v1:
 * Driver moved location
 * Put mkbp everywhere
 * Fixed up DT binding to not fail and make sure is a child of cros-ec
 * Simplified logic for sending a message
 * Dropped CONFIG_OF usage
 * Sorted includes

[1] https://lore.kernel.org/r/20201205004709.3126266-1-swb...@chromium.org

Cc: Dmitry Torokhov 
Cc: Benson Leung 
Cc: Guenter Roeck 
Cc: Douglas Anderson 
Cc: Gwendal Grignou 
Cc: 
Cc: Rob Herring 
Cc: Enric Balletbo i Serra 

Stephen Boyd (3):
  platform/chrome: cros_ec: Add SW_FRONT_PROXIMITY MKBP define
  dt-bindings: iio: Add cros ec proximity yaml doc
  iio: proximity: Add a ChromeOS EC MKBP proximity driver

 .../google,cros-ec-mkbp-proximity.yaml|  37 +++
 .../bindings/mfd/google,cros-ec.yaml  |   7 +
 drivers/iio/proximity/Kconfig |  11 +
 drivers/iio/proximity/Makefile|   1 +
 .../iio/proximity/cros_ec_mkbp_proximity.c| 271 ++
 .../linux/platform_data/cros_ec_commands.h|   1 +
 6 files changed, 328 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
 create mode 100644 drivers/iio/proximity/cros_ec_mkbp_proximity.c


base-commit: 19c329f6808995b142b3966301f217c831e7cf31
-- 
https://chromeos.dev

Re: [PATCH V3 1/2] dt-bindings: clk: versaclock5: Add optional load capacitance property

2021-02-10 Thread Stephen Boyd

Quoting Adam Ford (2021-02-10 12:40:38)
> On Wed, Feb 10, 2021 at 2:18 PM Rob Herring  wrote:
> >
> > On Sun, Feb 07, 2021 at 12:51:38PM -0600, Adam Ford wrote:
> > > There are two registers which can set the load capacitance for
> > > XTAL1 and XTAL2. These are optional registers when using an
> > > external crystal.  Since XTAL1 and XTAL2 will set to the same value,
> > > update the binding to support a single property called
> > > xtal-load-femtofarads.
> > >
> > > Signed-off-by: Adam Ford 
> > > ---
> > > V3:  No Change
> > > V2:  No Change
> > >
> > > A couple people suggested that I not use the $ref, but without it,
> > > the bindings check failed with errors.
> > >
> > > diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml 
> > > b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > > index 2ac1131fd922..c268debe5b8d 100644
> > > --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > > +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > > @@ -59,6 +59,12 @@ properties:
> > >  minItems: 1
> > >  maxItems: 2
> > >
> > > +  idt,xtal-load-femtofarads:
> > > +$ref: /schemas/types.yaml#/definitions/uint32
> >
> > Don't need a type with standard unit suffix.
> 
> If I remove that line, the binding check fails.
> 

Is your dt-schema up to date?

Re: [PATCH v3 1/5] clk: sunxi-ng: mp: fix parent rate change flag check

2021-02-10 Thread Stephen Boyd

Quoting Maxime Ripard (2021-02-10 02:29:04)
> Hi Mike, Stephen,
> 
> On Tue, Feb 09, 2021 at 06:58:56PM +0100, Jernej Skrabec wrote:
> > CLK_SET_RATE_PARENT flag is checked on parent clock instead of current
> > one. Fix that.
> > 
> > Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when 
> > allowed")
> > Reviewed-by: Chen-Yu Tsai 
> > Tested-by: Andre Heider 
> > Signed-off-by: Jernej Skrabec 
> 
> This is a last minute fix for us, can you merge it into clk-fixes directly?
> 
> Acked-by: Maxime Ripard 
> 

It's also fixing a problem that's been around since v5.0. Is something
broken that needs fixing this late? The motivation could be added to the
commit text because right now it looks like a typo fix spotted visually.

Re: [PATCH] lkdtm: don't move ctors to .rodata

2021-02-10 Thread Stephen Boyd

ds to be established before using it.

Having a dedicated section for such code allows to validate with tooling
that no unsafe functions are invoked.

Add the .noinstr.text section and the noinstr attribute to mark
functions. noinstr implies notrace. Kprobes will gain a section check
later.

Provide also a set of markers: instrumentation_begin()/end()

These are used to mark code inside a noinstr function which calls
into regular instrumentable text section as safe.

The instrumentation markers are only active when CONFIG_DEBUG_ENTRY is
enabled as the end marker emits a NOP to prevent the compiler from merging
the annotation points. This means the objtool verification requires a
kernel compiled with this option.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Alexandre Chartre 
Acked-by: Peter Zijlstra 
Link: https://lkml.kernel.org/r/20200505134100.075416...@linutronix.de
[swb...@chromium.org: Account for commit eff8728fe698 ("vmlinux.lds.h: Add
PGO and AutoFDO input sections") getting picked first]
Signed-off-by: Stephen Boyd 
---
 arch/powerpc/kernel/vmlinux.lds.S |  1 +
 include/asm-generic/sections.h|  3 ++
 include/asm-generic/vmlinux.lds.h | 10 ++
 include/linux/compiler.h  | 53 +++
 include/linux/compiler_types.h|  4 +++
 scripts/mod/modpost.c |  2 +-
 6 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
b/arch/powerpc/kernel/vmlinux.lds.S
index a4e576019d79..3ea360cad337 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -102,6 +102,7 @@ SECTIONS
 #ifdef CONFIG_PPC64
*(.tramp.ftrace.text);
 #endif
+   NOINSTR_TEXT
SCHED_TEXT
CPUIDLE_TEXT
LOCK_TEXT
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index d1779d442aa5..66397ed10acb 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -53,6 +53,9 @@ extern char __ctors_start[], __ctors_end[];
 /* Start and end of .opd section - used for function descriptors. */
 extern char __start_opd[], __end_opd[];
 
+/* Start and end of instrumentation protected text section */
+extern char __noinstr_text_start[], __noinstr_text_end[];
+
 extern __visible const void __nosave_begin, __nosave_end;
 
 /* Function descriptor handling (if any).  Override in asm/sections.h */
diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 130f16cc0b86..9a4a5a43e886 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -510,6 +510,15 @@
 #define RODATA  RO_DATA_SECTION(4096)
 #define RO_DATA(align)  RO_DATA_SECTION(align)
 
+/*
+ * Non-instrumentable text section
+ */
+#define NOINSTR_TEXT   \
+   ALIGN_FUNCTION();   \
+   __noinstr_text_start = .;   \
+   *(.noinstr.text)\
+   __noinstr_text_end = .;
+
 /*
  * .text section. Map to function alignment to avoid address changes
  * during second ld run in second ld pass when generating System.map
@@ -524,6 +533,7 @@
*(TEXT_MAIN .text.fixup)\
*(.text.unlikely .text.unlikely.*)  \
*(.text.unknown .text.unknown.*)\
+   NOINSTR_TEXT\
*(.text..refcount)  \
*(.ref.text)\
MEM_KEEP(init.text*)\
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index f164a9b12813..9446e8fbe55c 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -134,12 +134,65 @@ void ftrace_likely_update(struct ftrace_likely_data *f, 
int val,
 /* Annotate a C jump table to allow objtool to follow the code flow */
 #define __annotate_jump_table __section(.rodata..c_jump_table)
 
+#ifdef CONFIG_DEBUG_ENTRY
+/* Begin/end of an instrumentation safe region */
+#define instrumentation_begin() ({ \
+   asm volatile("%c0:\n\t" \
+".pushsection .discard.instr_begin\n\t"\
+".long %c0b - .\n\t"   \
+".popsection\n\t" : : "i" (__COUNTER__));  \
+})
+
+/*
+ * Because instrumentation_{begin,end}() can nest, objtool validation considers
+ * _begin() a +1 and _end() a -1 and computes a sum over the instructions.
+ * When the value is greater than 0, we consider instrumentation allowed.
+ *
+ * There is a problem with code like:
+ *
+

Re: [PATCH v5 3/3] iio: proximity: Add a ChromeOS EC MKBP proximity driver

2021-02-10 Thread Stephen Boyd

Quoting Gwendal Grignou (2021-02-10 00:29:45)
> On Tue, Feb 9, 2021 at 6:51 PM Stephen Boyd  wrote:
> > +   if (event_type == EC_MKBP_EVENT_SWITCH) {
> > +   data = container_of(nb, struct cros_ec_mkbp_proximity_data,
> > +   notifier);
> > +   indio_dev = data->indio_dev;
> > +
> > +   mutex_lock(>lock);
> > +   if (data->enabled) {
> > +   timestamp = ktime_to_ns(ec->last_event_time);
> Note to self, ktime_to_ns is a noop, but make code cleaner: need to
> change other access to ec->last_event_time.
>
> > +   if (iio_device_get_clock(indio_dev) != 
> > CLOCK_BOOTTIME)
> > +   timestamp = iio_get_time_ns(indio_dev);
> > +   state = 
> > cros_ec_mkbp_proximity_parse_state(switches);
>
> There can be several switches in the EC (lid open, tablet mode, ...),
> so you can get a switch event even when the proximity switch did not
> trigger.
> You can keep the current state and push an iio event only when there
> is a change. See cbas_ec_notify().
>

Ah ok. So we'll have to save a state tracking variable and poll the bit
once at boot and then at resume time? What happens to events that happen
across suspend/resume? We drop them? Or we need to inject the last state
if it's different into IIO with the time of resume?

> > +   dir = state ? IIO_EV_DIR_FALLING : 
> > IIO_EV_DIR_RISING;
> > +
> > +   ev = IIO_UNMOD_EVENT_CODE(IIO_PROXIMITY, 0,
> > + IIO_EV_TYPE_THRESH, dir);
> > +   iio_push_event(indio_dev, ev, timestamp);
> > +   }
> > +   mutex_unlock(>lock);
> > +   }
> > +
> > +   return NOTIFY_OK;
> > +}
> > +
> > +static int cros_ec_mkbp_proximity_read_raw(struct iio_dev *indio_dev,
> > +  const struct iio_chan_spec *chan, int *val,
> > +  int *val2, long mask)
> > +{
> > +   struct cros_ec_mkbp_proximity_data *data = iio_priv(indio_dev);
> > +   struct cros_ec_device *ec = data->ec;
> > +
> > +   if (chan->type != IIO_PROXIMITY)
> > +   return -EINVAL;
> > +
> > +   switch (mask) {
>
> A switch is not necessary here.

Ok.

> > +   case IIO_CHAN_INFO_RAW:

[PATCH v5 1/3] platform/chrome: cros_ec: Add SW_FRONT_PROXIMITY MKBP define

2021-02-09 Thread Stephen Boyd

Some cros ECs support a front proximity MKBP event via
'EC_MKBP_FRONT_PROXIMITY'. Add this define so it can be used in a
future patch.

Cc: Dmitry Torokhov 
Cc: Benson Leung 
Cc: Guenter Roeck 
Cc: Douglas Anderson 
Cc: Gwendal Grignou 
Acked-by: Enric Balletbo i Serra 
Signed-off-by: Stephen Boyd 
---

No changes from last time.

 include/linux/platform_data/cros_ec_commands.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/platform_data/cros_ec_commands.h 
b/include/linux/platform_data/cros_ec_commands.h
index 86376779ab31..776e0b2be0e9 100644
--- a/include/linux/platform_data/cros_ec_commands.h
+++ b/include/linux/platform_data/cros_ec_commands.h
@@ -3457,6 +3457,7 @@ struct ec_response_get_next_event_v1 {
 #define EC_MKBP_LID_OPEN   0
 #define EC_MKBP_TABLET_MODE1
 #define EC_MKBP_BASE_ATTACHED  2
+#define EC_MKBP_FRONT_PROXIMITY3
 
 /* Run keyboard factory test scanning */
 #define EC_CMD_KEYBOARD_FACTORY_TEST 0x0068
-- 
https://chromeos.dev

[PATCH v5 3/3] iio: proximity: Add a ChromeOS EC MKBP proximity driver

2021-02-09 Thread Stephen Boyd

Add support for a ChromeOS EC proximity driver that exposes a "front"
proximity sensor via the IIO subsystem. The EC decides when front
proximity is near and sets an MKBP switch 'EC_MKBP_FRONT_PROXIMITY' to
notify the kernel of proximity. Similarly, when proximity detects
something far away it sets the switch bit to 0. For now this driver
exposes a single sensor, but it could be expanded in the future via more
MKBP bits if desired.

Cc: Dmitry Torokhov 
Cc: Benson Leung 
Cc: Guenter Roeck 
Cc: Douglas Anderson 
Cc: Gwendal Grignou 
Reviewed-by: Enric Balletbo i Serra 
Signed-off-by: Stephen Boyd 
---

Changes from v4:
 * Dropped of_match_ptr()

 drivers/iio/proximity/Kconfig |  11 +
 drivers/iio/proximity/Makefile|   1 +
 .../iio/proximity/cros_ec_mkbp_proximity.c| 242 ++
 3 files changed, 254 insertions(+)
 create mode 100644 drivers/iio/proximity/cros_ec_mkbp_proximity.c

diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
index 12672a0e89ed..7c7203ca3ac6 100644
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -21,6 +21,17 @@ endmenu
 
 menu "Proximity and distance sensors"
 
+config CROS_EC_MKBP_PROXIMITY
+   tristate "ChromeOS EC MKBP Proximity sensor"
+   depends on CROS_EC
+   help
+ Say Y here to enable the proximity sensor implemented via the 
ChromeOS EC MKBP
+ switches protocol. You must enable one bus option (CROS_EC_I2C or 
CROS_EC_SPI)
+ to use this.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cros_ec_mkbp_proximity.
+
 config ISL29501
tristate "Intersil ISL29501 Time Of Flight sensor"
depends on I2C
diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
index 9c1aca1a8b79..cbdac09433eb 100644
--- a/drivers/iio/proximity/Makefile
+++ b/drivers/iio/proximity/Makefile
@@ -5,6 +5,7 @@
 
 # When adding new entries keep the list in alphabetical order
 obj-$(CONFIG_AS3935)   += as3935.o
+obj-$(CONFIG_CROS_EC_MKBP_PROXIMITY) += cros_ec_mkbp_proximity.o
 obj-$(CONFIG_ISL29501) += isl29501.o
 obj-$(CONFIG_LIDAR_LITE_V2)+= pulsedlight-lidar-lite-v2.o
 obj-$(CONFIG_MB1232)   += mb1232.o
diff --git a/drivers/iio/proximity/cros_ec_mkbp_proximity.c 
b/drivers/iio/proximity/cros_ec_mkbp_proximity.c
new file mode 100644
index ..2cdaf05c0ec2
--- /dev/null
+++ b/drivers/iio/proximity/cros_ec_mkbp_proximity.c
@@ -0,0 +1,242 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for cros-ec proximity sensor exposed through MKBP switch
+ *
+ * Copyright 2021 Google LLC.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+struct cros_ec_mkbp_proximity_data {
+   struct cros_ec_device *ec;
+   struct iio_dev *indio_dev;
+   struct mutex lock;
+   struct notifier_block notifier;
+   bool enabled;
+};
+
+static const struct iio_event_spec cros_ec_mkbp_proximity_events[] = {
+   {
+   .type = IIO_EV_TYPE_THRESH,
+   .dir = IIO_EV_DIR_EITHER,
+   .mask_separate = BIT(IIO_EV_INFO_ENABLE),
+   },
+};
+
+static const struct iio_chan_spec cros_ec_mkbp_proximity_chan_spec[] = {
+   {
+   .type = IIO_PROXIMITY,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+   .event_spec = cros_ec_mkbp_proximity_events,
+   .num_event_specs = ARRAY_SIZE(cros_ec_mkbp_proximity_events),
+   },
+};
+
+static int cros_ec_mkbp_proximity_parse_state(const void *data)
+{
+   u32 switches = get_unaligned_le32(data);
+
+   return !!(switches & BIT(EC_MKBP_FRONT_PROXIMITY));
+}
+
+static int cros_ec_mkbp_proximity_query(struct cros_ec_device *ec_dev,
+   int *state)
+{
+   struct {
+   struct cros_ec_command msg;
+   union {
+   struct ec_params_mkbp_info params;
+   u32 switches;
+   };
+   } __packed buf = { };
+   struct ec_params_mkbp_info *params = 
+   struct cros_ec_command *msg = 
+   u32 *switches = 
+   size_t insize = sizeof(*switches);
+   int ret;
+
+   msg->command = EC_CMD_MKBP_INFO;
+   msg->version = 1;
+   msg->outsize = sizeof(*params);
+   msg->insize = insize;
+
+   params->info_type = EC_MKBP_INFO_CURRENT;
+   params->event_type = EC_MKBP_EVENT_SWITCH;
+
+   ret = cros_ec_cmd_xfer_status(ec_dev, msg);
+   if (ret < 0)
+   return ret;
+
+   if (ret != insize) {
+   dev_warn(ec_dev->dev, "wrong result size: %d != %zu\n", ret,
+insize);
+   return -EPROTO;
+   }
+
+   *state = cros_ec_mkbp

[PATCH v5 2/3] dt-bindings: iio: Add cros ec proximity yaml doc

2021-02-09 Thread Stephen Boyd

Some cros ECs support a front proximity MKBP event via
'EC_MKBP_FRONT_PROXIMITY'. Add a DT binding to document this feature via
a node that is a child of the main cros_ec device node. Devices that
have this ability will describe this in firmware.

Cc: Dmitry Torokhov 
Cc: Benson Leung 
Cc: Guenter Roeck 
Cc: Douglas Anderson 
Cc: Gwendal Grignou 
Cc: 
Cc: Rob Herring 
Cc: Enric Balletbo i Serra 
Signed-off-by: Stephen Boyd 
---

Changes from v4:
 * Reduced example in iio binding and moved to mfd
 * Dropped unevaluatedProperties

 .../google,cros-ec-mkbp-proximity.yaml| 37 +++
 .../bindings/mfd/google,cros-ec.yaml  |  7 
 2 files changed, 44 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml

diff --git 
a/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
 
b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
new file mode 100644
index ..099b4be927d4
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: 
http://devicetree.org/schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ChromeOS EC MKBP Proximity Sensor
+
+maintainers:
+  - Stephen Boyd 
+  - Benson Leung 
+  - Enric Balletbo i Serra 
+
+description: |
+  Google's ChromeOS EC sometimes has the ability to detect user proximity.
+  This is implemented on the EC as near/far logic and exposed to the OS
+  via an MKBP switch bit.
+
+properties:
+  compatible:
+const: google,cros-ec-mkbp-proximity
+
+  label:
+description: Name for proximity sensor
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+proximity {
+  compatible = "google,cros-ec-mkbp-proximity";
+  label = "proximity-wifi-lte";
+};
diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml 
b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
index 76bf16ee27ec..4dfa70a013ae 100644
--- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
+++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
@@ -94,6 +94,9 @@ properties:
   keyboard-controller:
 $ref: "/schemas/input/google,cros-ec-keyb.yaml#"
 
+  proximity:
+$ref: "/schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#"
+
   codecs:
 type: object
 additionalProperties: false
@@ -180,6 +183,10 @@ examples:
 interrupts = <99 0>;
 interrupt-parent = <>;
 spi-max-frequency = <500>;
+
+proximity {
+compatible = "google,cros-ec-mkbp-proximity";
+};
 };
 };
 
-- 
https://chromeos.dev

[PATCHv5 0/3] iio: Add a ChromeOS EC MKBP proximity driver

2021-02-09 Thread Stephen Boyd

This is a different approach to [1] where I tried to add this proximity
sensor logic to the input subsystem. Instead, we'll take the approach of
making a small IIO proximity driver that parses the EC switch bitmap to
find out if the front proximity sensor is detecting something or not.
This allows us to treat proximity sensors as IIO devices all the time in
userspace instead of handling this switch on the EC via the input
subsystem and then other proximity sensors via IIO.

I propose this is all merged through IIO subsystem. Please ack
the first patch so it can be merged that way.

Changes from v4:
 * Reduced binding and moved proximity node to mfd spi example
 * Dropped of_match_ptr()

Changes from v3:
 * Added SPI and cros-ec wrapper nodes to yaml example
 * Ignore notifier registration return code that is always zero

Changes from v2:
 * Check iio clock and use IIO time if not boottime

Changes from v1:
 * Driver moved location
 * Put mkbp everywhere
 * Fixed up DT binding to not fail and make sure is a child of cros-ec
 * Simplified logic for sending a message
 * Dropped CONFIG_OF usage
 * Sorted includes

[1] https://lore.kernel.org/r/20201205004709.3126266-1-swb...@chromium.org

Cc: Dmitry Torokhov 
Cc: Benson Leung 
Cc: Guenter Roeck 
Cc: Douglas Anderson 
Cc: Gwendal Grignou 
Cc: 
Cc: Rob Herring 
Cc: Enric Balletbo i Serra 

Stephen Boyd (3):
  platform/chrome: cros_ec: Add SW_FRONT_PROXIMITY MKBP define
  dt-bindings: iio: Add cros ec proximity yaml doc
  iio: proximity: Add a ChromeOS EC MKBP proximity driver

 .../google,cros-ec-mkbp-proximity.yaml|  37 +++
 .../bindings/mfd/google,cros-ec.yaml  |   7 +
 drivers/iio/proximity/Kconfig |  11 +
 drivers/iio/proximity/Makefile|   1 +
 .../iio/proximity/cros_ec_mkbp_proximity.c| 242 ++
 .../linux/platform_data/cros_ec_commands.h|   1 +
 6 files changed, 299 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
 create mode 100644 drivers/iio/proximity/cros_ec_mkbp_proximity.c


base-commit: 19c329f6808995b142b3966301f217c831e7cf31
-- 
https://chromeos.dev

Re: [PATCH v4 3/3] iio: proximity: Add a ChromeOS EC MKBP proximity driver

2021-02-09 Thread Stephen Boyd

Quoting Stephen Boyd (2021-02-06 19:21:39)
> Quoting Jonathan Cameron (2021-02-06 08:17:11)
> > On Tue,  2 Feb 2021 10:44:34 -0800
> > Stephen Boyd  wrote:
> > 
> > > +static struct platform_driver cros_ec_mkbp_proximity_driver = {
> > > + .driver = {
> > > + .name = "cros-ec-mkbp-proximity",
> > > + .of_match_table = 
> > > of_match_ptr(cros_ec_mkbp_proximity_of_match),
> > I'm going to assume we know no one is going to use this with
> > ACPI via PRP0001 given presumably the firmware on these devices
> > is tightly controlled.
> 
> Correct.
> 
> > 
> > However, we should should still drop the of_match_ptr
> > as it will lead to an unused warning for cros_ec_mkbp_proximity_of_match
> > if anyone builds this without CONFIG_OF + it sets a general bad
> > precedence that I'd rather wasn't around for people to copy.
> > Note that in general we are slowly ripping these out of IIO but
> > probably lots still there.
> > 
> > If this is all that is needed in this version I'll just do it
> > whilst applying unless anyone shouts.
> > 
> 
> Agreed. Thanks for fixing that last little bit.

Seems Rob wanted a small tweak to the binding so I'll resend this now
and drop the of_match_ptr() usage.

Re: [PATCH v4 2/3] dt-bindings: iio: Add cros ec proximity yaml doc

2021-02-09 Thread Stephen Boyd

Quoting Rob Herring (2021-02-09 13:13:47)
> On Tue, Feb 02, 2021 at 10:44:33AM -0800, Stephen Boyd wrote:
> > +description: Name for proximity sensor
> > +
> > +required:
> > +  - compatible
> > +
> > +unevaluatedProperties: false
> > +additionalProperties: false
> 
> Only need one. In this case 'additionalProperties'.

Got it.

> 
> > +
> > +examples:
> > +  - |
> > +spi {
> > +  #address-cells = <1>;
> > +  #size-cells = <0>;
> > +  ec@0 {
> > +compatible = "google,cros-ec-spi";
> > +reg = <0>;
> > +proximity {
> > +  compatible = "google,cros-ec-mkbp-proximity";
> > +  label = "proximity-wifi-lte";
> > +};
> 
> The complete examples I prefer is 1 example for the whole MFD in the MFD 
> schema and no example here.

Alright. I can add it to the mfd binding instead.

> 
> > +  };
> > +};
> > diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml 
> > b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> > index 76bf16ee27ec..479a9f15de32 100644
> > --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> > +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> > @@ -94,6 +94,9 @@ properties:
> >keyboard-controller:
> >  $ref: "/schemas/input/google,cros-ec-keyb.yaml#"

Re: [PATCH 2/6] dt-bindings: clk: mstar msc313 mpll binding description

2021-02-09 Thread Stephen Boyd

Quoting Daniel Palmer (2020-12-21 00:51:56)
> Hi Stephen,
> 
> On Mon, 21 Dec 2020 at 03:44, Stephen Boyd  wrote:
> >
> > Quoting Daniel Palmer (2020-12-19 22:35:41)
> > > Hi Stephen,
> > >
> > > On Sun, 20 Dec 2020 at 12:39, Stephen Boyd  wrote:
> > > > > +  clock-output-names:
> > > > > +minItems: 8
> > > > > +maxItems: 8
> > > > > +description: |
> > > > > +  This should provide a name for the internal PLL clock and then
> > > > > +  a name for each of the divided outputs.
> > > >
> > > > Is this necessary?
> > >
> > > I found without the names specified in the dt probing of muxes that
> > > depend on the outputs but appear earlier didn't work.
> > > Also this same PLL layout seems to be used in some other places so
> > > eventually I was thinking this driver would get used for those PLLs
> > > with different output names.
> >
> > Still seems like it could be auto-generated based on dev_name() +
> > number.
> 
> At one point I had something similar to that where the output names
> were generated at probe.
> Without the clock outputs listed in the device tree clock muxes that
> source clocks from the mpll couldn't probe properly as they couldn't
> look up all of their parents if they probed before the mpll.
> Maybe I'm doing something wrong there? I couldn't find a way to always
> resolve all of the parents or defer the probe of the muxes until the
> mpll clocks are registered.
> 

The child clks should be using clk_parent_data to point to the parent
clks through DT. That way the name of the clk doesn't matter except for
debug purposes.

Re: [PATCH mvebu v2 06/10] clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1 to L0

2021-02-09 Thread Stephen Boyd

Quoting Pali Rohár (2021-01-14 04:40:28)
> When CPU frequency is at 250 MHz and set_rate() is called with 500 MHz (L1)
> quickly followed by a call with 1 GHz (L0), the CPU does not necessarily
> stay in L1 for at least 20ms as is required by Marvell errata.
> 
> This situation happens frequently with the ondemand cpufreq governor and
> can be also reproduced with userspace governor. In most cases it causes CPU
> to crash.
> 
> This change fixes the above issue and ensures that the CPU always stays in
> L1 for at least 20ms when switching from any state to L0.
> 
> Signed-off-by: Marek Behún 
> Signed-off-by: Pali Rohár 
> Fixes: 61c40f35f5cd ("clk: mvebu: armada-37xx-periph: Fix switching CPU rate 
> from 300Mhz to 1.2GHz")
> Cc: sta...@vger.kernel.org
> ---

Acked-by: Stephen Boyd

Re: [PATCH mvebu v2 05/10] clk: mvebu: armada-37xx-periph: Fix switching CPU freq from 250 Mhz to 1 GHz

2021-02-09 Thread Stephen Boyd

Quoting Pali Rohár (2021-01-14 04:40:27)
> It was observed that the workaround introduced by commit 61c40f35f5cd
> ("clk: mvebu: armada-37xx-periph: Fix switching CPU rate from 300Mhz to
> 1.2GHz") when base CPU frequency is 1.2 GHz is also required when base
> CPU frequency is 1 GHz. Otherwise switching CPU frequency directly from
> L2 (250 MHz) to L0 (1 GHz) causes a crash.
> 
> When base CPU frequency is just 800 MHz no crashed were observed during
> switch from L2 to L0.
> 
> Signed-off-by: Pali Rohár 
> Fixes: 2089dc33ea0e ("clk: mvebu: armada-37xx-periph: add DVFS support for 
> cpu clocks")
> Cc: sta...@vger.kernel.org # 61c40f35f5cd ("clk: mvebu: armada-37xx-periph: 
> Fix switching CPU rate from 300Mhz to 1.2GHz")
> ---

Acked-by: Stephen Boyd

Re: [PATCH mvebu v2 03/10] clk: mvebu: armada-37xx-periph: remove .set_parent method for CPU PM clock

2021-02-09 Thread Stephen Boyd

Quoting Pali Rohár (2021-01-14 04:40:25)
> From: Marek Behún 
> 
> Remove the .set_parent method in clk_pm_cpu_ops.
> 
> This method was supposed to be needed by the armada-37xx-cpufreq driver,
> but was never actually called due to wrong assumptions in the cpufreq
> driver. After this was fixed in the cpufreq driver, this method is not
> needed anymore.
> 
> Signed-off-by: Marek Behún 
> Fixes: 2089dc33ea0e ("clk: mvebu: armada-37xx-periph: add DVFS support for 
> cpu clocks")
> Cc: Gregory CLEMENT 
> Cc: Miquel Raynal 
> ---

Acked-by: Stephen Boyd

Re: [PATCH] clk: at91: Fix the declaration of the clocks

2021-02-09 Thread Stephen Boyd

Quoting Tudor Ambarus (2021-02-03 07:43:32)
> These are all "early clocks" that require initialization just at
> of_clk_init() time. Use CLK_OF_DECLARE() to declare them.
> 
> This also fixes a problem that was spotted when fw_devlink was
> set to 'on' by default: the boards failed to boot. The reason is
> that CLK_OF_DECLARE_DRIVER() clears the OF_POPULATED and causes
> the consumers of the clock to be postponed by fw_devlink until
> the second initialization routine of the clock has been completed.
> One of the consumers of the clock is the timer, which is used as a
> clocksource, and needs the clock initialized early. Postponing the
> timers caused the fail at boot.
> 
> Signed-off-by: Tudor Ambarus 
> ---

Applied to clk-next

Re: [PATCH] clk: at91: Fix the declaration of the clocks

2021-02-09 Thread Stephen Boyd

Quoting tudor.amba...@microchip.com (2021-02-08 01:49:45)
> Hi, Michael, Stephen,
> 
> Do you plan to take this patch for v5.12?
> If fw_devlink will remain set to ON for v5.12, some of our boards will
> no longer boot without this patch.

Is fw_devlink defaulted to on for v5.12?

Re: [PATCH v2 02/14] clk: stm32mp1: merge 'ck_hse_rtc' and 'ck_rtc' into one clock

2021-02-09 Thread Stephen Boyd

Quoting gabriel.fernan...@foss.st.com (2021-01-26 01:01:08)
> From: Gabriel Fernandez 
> 
> 'ck_rtc' has multiple clocks as input (ck_hsi, ck_lsi, and ck_hse).
> A divider is available only on the specific rtc input for ck_hse.
> This Merge will facilitate to have a more coherent clock tree
> in no trusted / trusted world.
> 
> Signed-off-by: Gabriel Fernandez 
> ---
>  drivers/clk/clk-stm32mp1.c | 49 +-
>  1 file changed, 43 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
> index 35d5aee8f9b0..0e1d4427a8df 100644
> --- a/drivers/clk/clk-stm32mp1.c
> +++ b/drivers/clk/clk-stm32mp1.c
> @@ -245,7 +245,7 @@ static const char * const dsi_src[] = {
>  };
>  
>  static const char * const rtc_src[] = {
> -   "off", "ck_lse", "ck_lsi", "ck_hse_rtc"
> +   "off", "ck_lse", "ck_lsi", "ck_hse"
>  };
>  
>  static const char * const mco1_src[] = {
> @@ -1031,6 +1031,42 @@ static struct clk_hw *clk_register_cktim(struct device 
> *dev, const char *name,
> return hw;
>  }
>  
> +/* The divider of RTC clock concerns only ck_hse clock */
> +#define HSE_RTC 3
> +
> +static unsigned long clk_divider_rtc_recalc_rate(struct clk_hw *hw,
> +unsigned long parent_rate)
> +{
> +   if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
> +   return clk_divider_ops.recalc_rate(hw, parent_rate);
> +
> +   return parent_rate;
> +}
> +
> +static long clk_divider_rtc_round_rate(struct clk_hw *hw, unsigned long rate,
> +  unsigned long *prate)
> +{
> +   if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))

This clk op can be called at basically any time. Maybe this should use
the determine rate op and then look to see what the parent is that comes
in via the rate request structure? Or is the intention to keep this
pinned to one particular parent? Looking at this right now it doesn't
really make much sense why the current parent state should play into
what rate the clk can round to, unless there is some more clk flags
going on that constrain the ability to change this clk's parent.

> +   return clk_divider_ops.round_rate(hw, rate, prate);
> +
> +   return *prate;
> +}
> +
> +static int clk_divider_rtc_set_rate(struct clk_hw *hw, unsigned long rate,
> +   unsigned long parent_rate)
> +{
> +   if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
> +   return clk_divider_ops.set_rate(hw, rate, parent_rate);
> +
> +   return parent_rate;
> +}
> +

Re: [PATCH] clk: at91: sama5d2: Mark device OF_POPULATED after setup

2021-02-08 Thread Stephen Boyd

Quoting Saravana Kannan (2021-01-28 09:01:41)
> On Thu, Jan 28, 2021 at 2:45 AM Tudor Ambarus
>  wrote:
> >
> > The sama5d2 requires the clock provider initialized before timers.
> > We can't use a platform driver for the sama5d2-pmc driver, as the
> > platform_bus_init() is called later on, after time_init().
> >
> > As fw_devlink considers only devices, it does not know that the
> > pmc is ready. Hence probing of devices that depend on it fail:
> > probe deferral - supplier f0014000.pmc not ready
> >
> > Fix this by setting the OF_POPULATED flag for the sama5d2_pmc
> > device node after successful setup. This will make
> > of_link_to_phandle() ignore the sama5d2_pmc device node as a
> > dependency, and consumer devices will be probed again.
> >
> > Fixes: e590474768f1cc04 ("driver core: Set fw_devlink=on by default")
> > Signed-off-by: Tudor Ambarus 
> > ---
> > I'll be out of office, will check the rest of the at91 SoCs
> > at the begining of next week.
> >
> >  drivers/clk/at91/sama5d2.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
> > index 9a5cbc7cd55a..5eea2b4a63dd 100644
> > --- a/drivers/clk/at91/sama5d2.c
> > +++ b/drivers/clk/at91/sama5d2.c
> > @@ -367,6 +367,8 @@ static void __init sama5d2_pmc_setup(struct device_node 
> > *np)
> >
> > of_clk_add_hw_provider(np, of_clk_hw_pmc_get, sama5d2_pmc);
> >
> > +   of_node_set_flag(np, OF_POPULATED);
> > +
> > return;
> 
> Hi Tudor,
> 
> Thanks for looking into this.
> 
> I already accounted for early clocks like this when I designed
> fw_devlink. Each driver shouldn't need to set OF_POPULATED.
> drivers/clk/clk.c already does this for you.
> 
> I think the problem is that your driver is using
> CLK_OF_DECLARE_DRIVER() instead of CLK_OF_DECLARE(). The comments for
> CLK_OF_DECLARE_DRIVER() says:
> /*
>  * Use this macro when you have a driver that requires two initialization
>  * routines, one at of_clk_init(), and one at platform device probe
>  */
> 
> In your case, you are explicitly NOT having a driver bind to this
> clock later. So you shouldn't be using CLK_OF_DECLARE() instead.
> 

I see 

drivers/power/reset/at91-sama5d2_shdwc.c:   { .compatible = 
"atmel,sama5d2-pmc" },

so isn't that the driver that wants to bind to the same device node
again? First at of_clk_init() time here and then second for the reset
driver?

Re: [PATCH v3] clk: exynos7: Keep aclk_fsys1_200 enabled

2021-02-08 Thread Stephen Boyd

Quoting (2021-01-31 09:04:28)
> This clock must be always enabled to allow access to any registers in
> fsys1 CMU. Until proper solution based on runtime PM is applied
> (similar to what was done for Exynos5433), fix this by calling
> clk_prepare_enable() directly from clock provider driver.
> 
> It was observed on Samsung Galaxy S6 device (based on Exynos7420), where
> UFS module is probed before pmic used to power that device.
> In this case defer probe was happening and that clock was disabled by
> UFS driver, causing whole boot to hang on next CMU access.
> 

Does this need a Fixes tag?

Re: [PATCH] clk: mediatek: Select all the MT8183 clocks by default

2021-02-08 Thread Stephen Boyd

Quoting Enric Balletbo i Serra (2021-02-03 02:54:23)
> If MT8183 SoC support is enabled, almost all machines will use topckgen,
> apmixedsys, infracfg, mcucfg and subsystem clocks, so it feels wrong to
> require each one to select that symbols manually.
> 
> Instead, enable it whenever COMMON_CLK_MT8183_* is disabled as
> a simplification. This would add few KB in the kernel image size but
> will make the life a bit easier to the users, anyway you'll need to probably
> enable all of them if you want to have proper support for that SoC.
> 
> Signed-off-by: Enric Balletbo i Serra 
> ---

Applied to clk-next

Re: [PATCH v3 4/4] clk: axi-clkgen: use devm_platform_ioremap_resource() short-hand

2021-02-08 Thread Stephen Boyd

Quoting Alexandru Ardelean (2021-02-01 07:12:45)
> No major functional change. Noticed while checking the driver code that
> this could be used.
> Saves two lines.
> 
> Signed-off-by: Alexandru Ardelean 
> ---

Applied to clk-next

Re: [PATCH v3 3/4] dt-bindings: clock: adi,axi-clkgen: add compatible string for ZynqMP support

2021-02-08 Thread Stephen Boyd

Quoting Alexandru Ardelean (2021-02-01 07:12:44)
> The axi-clkgen driver now supports ZynqMP (UltraScale) as well, however the
> driver needs to use different PFD & VCO limits.
> 
> For ZynqMP, these needs to be selected by using the
> 'adi,zynqmp-axi-clkgen-2.00.a' string.
> 
> Signed-off-by: Alexandru Ardelean 
> ---

Applied to clk-next

Re: [PATCH v3 2/4] clk: clk-axiclkgen: add ZynqMP PFD and VCO limits

2021-02-08 Thread Stephen Boyd

Quoting Alexandru Ardelean (2021-02-01 07:12:43)
> For ZynqMP (Ultrascale) the PFD and VCO limits are different. In order to
> support these, this change adds a compatible string (i.e.
> 'adi,zynqmp-axi-clkgen-2.00.a')  which will take into account for these
> limits and apply them.
> 
> Signed-off-by: Dragos Bogdan 
> Signed-off-by: Mathias Tausen 
> Signed-off-by: Alexandru Ardelean 
> ---

Applied to clk-next

Re: [PATCH v3 1/4] clk: axi-clkgen: replace ARCH dependencies with driver deps

2021-02-08 Thread Stephen Boyd

Quoting Alexandru Ardelean (2021-02-01 07:12:42)
> The intent is to be able to run this driver to access the IP core in setups
> where FPGA board is also connected via a PCIe bus. In such cases the number
> of combinations explodes, where the host system can be an x86 with Xilinx
> Zynq/ZynqMP/Microblaze board connected via PCIe.
> Or even a ZynqMP board with a ZynqMP/Zynq/Microblaze connected via PCIe.
> 
> To accommodate for these cases, this change removes the limitation for this
> driver to be compilable only on Zynq/Microblaze architectures.
> And adds dependencies on the mechanisms required by the driver to work (OF
> and HAS_IOMEM).
> 
> Signed-off-by: Dragos Bogdan 
> Signed-off-by: Alexandru Ardelean 
> ---

Applied to clk-next

Re: [PATCH v6 00/22] Mediatek MT8192 clock support

2021-02-08 Thread Stephen Boyd

Quoting Weiyi Lu (2020-12-22 05:09:25)
> This series is based on v5.10-rc1.
> 

The DT bindings fail, can you fix and resend?

Documentation/devicetree/bindings/arm/mediatek/mediatek,msdc.yaml: 
'additionalProperties' is a required property
Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.yaml: 
'additionalProperties' is a required property
Documentation/devicetree/bindings/arm/mediatek/mediatek,mdpsys.yaml: 
'additionalProperties' is a required property
Documentation/devicetree/bindings/arm/mediatek/mediatek,scp-adsp.yaml: 
'additionalProperties' is a required property
Documentation/devicetree/bindings/arm/mediatek/mediatek,msdc.yaml: ignoring, 
error in schema:
warning: no schema found in file: 
Documentation/devicetree/bindings/arm/mediatek/mediatek,msdc.yaml
Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.yaml: 
ignoring, error in schema:
warning: no schema found in file: 
Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.yaml
Documentation/devicetree/bindings/arm/mediatek/mediatek,mdpsys.yaml: ignoring, 
error in schema:
warning: no schema found in file: 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mdpsys.yaml
Documentation/devicetree/bindings/arm/mediatek/mediatek,scp-adsp.yaml: 
ignoring, error in schema:
warning: no schema found in file: 
Documentation/devicetree/bindings/arm/mediatek/mediatek,scp-adsp.yaml
Documentation/devicetree/bindings/arm/mediatek/mediatek,msdc.example.dt.yaml: 
example-0: syscon@11f6:reg:0: [0, 301334528, 0, 4096] is too long
From schema: 
~/.local/lib/python3.8/site-packages/dtschema/schemas/reg.yaml
Documentation/devicetree/bindings/arm/mediatek/mediatek,msdc.example.dt.yaml: 
example-1: syscon@11f1:reg:0: [0, 301006848, 0, 4096] is too long
From schema: 
~/.local/lib/python3.8/site-packages/dtschema/schemas/reg.yaml
Documentation/devicetree/bindings/arm/mediatek/mediatek,mdpsys.example.dt.yaml: 
example-0: syscon@1f00:reg:0: [0, 520093696, 0, 4096] is too long
From schema: 
~/.local/lib/python3.8/site-packages/dtschema/schemas/reg.yaml
Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.example.dt.yaml:
 example-0: syscon@11007000:reg:0: [0, 285241344, 0, 4096] is too long
From schema: 
~/.local/lib/python3.8/site-packages/dtschema/schemas/reg.yaml
Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.example.dt.yaml:
 example-1: syscon@11cb1000:reg:0: [0, 298520576, 0, 4096] is too long
From schema: 
~/.local/lib/python3.8/site-packages/dtschema/schemas/reg.yaml
Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.example.dt.yaml:
 example-2: syscon@11d03000:reg:0: [0, 298856448, 0, 4096] is too long
From schema: 
~/.local/lib/python3.8/site-packages/dtschema/schemas/reg.yaml
Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.example.dt.yaml:
 example-3: syscon@11d23000:reg:0: [0, 298987520, 0, 4096] is too long
From schema: 
~/.local/lib/python3.8/site-packages/dtschema/schemas/reg.yaml
Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.example.dt.yaml:
 example-4: syscon@11e01000:reg:0: [0, 299896832, 0, 4096] is too long
From schema: 
~/.local/lib/python3.8/site-packages/dtschema/schemas/reg.yaml
Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.example.dt.yaml:
 example-5: syscon@11f02000:reg:0: [0, 300949504, 0, 4096] is too long
From schema: 
~/.local/lib/python3.8/site-packages/dtschema/schemas/reg.yaml

Re: [PATCH v6 2/4] soc: qcom: Add SoC sleep stats driver

2021-02-08 Thread Stephen Boyd

Quoting Maulik Shah (2021-02-04 06:21:46)
> From: Mahesh Sivasubramanian 
> 
> Let's add a driver to read the stats from remote processor and
> export to debugfs.
> 
> The driver creates "qcom_sleep_stats" directory in debugfs and
> adds files for various low power mode available. Below is sample
> output with command
> 
> cat /sys/kernel/debug/qcom_sleep_stats/ddr

The ddr subsystem isn't listed below in subsystems though. Can the
example be updated to reflect what is supported? Or can we gain the ddr
subsystem?

> count = 0
> Last Entered At = 0
> Last Exited At = 0
> Accumulated Duration = 0
> 
> Signed-off-by: Mahesh Sivasubramanian 
> Signed-off-by: Lina Iyer 
> [mkshah: add subsystem sleep stats, create one file for each stat]
> Signed-off-by: Maulik Shah 
> ---
>  drivers/soc/qcom/Kconfig   |  10 ++
>  drivers/soc/qcom/Makefile  |   1 +
>  drivers/soc/qcom/soc_sleep_stats.c | 258 
> +
>  3 files changed, 269 insertions(+)
>  create mode 100644 drivers/soc/qcom/soc_sleep_stats.c
> 
> diff --git a/drivers/soc/qcom/soc_sleep_stats.c 
> b/drivers/soc/qcom/soc_sleep_stats.c
> new file mode 100644
> index 000..66df638
> --- /dev/null
> +++ b/drivers/soc/qcom/soc_sleep_stats.c
> @@ -0,0 +1,258 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2011-2021, The Linux Foundation. All rights reserved.
> + */
> +
> +#include 

Any chance to get off of debugfs and expose this in sysfs instead?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define STAT_TYPE_ADDR 0x0
> +#define COUNT_ADDR 0x4
> +#define LAST_ENTERED_AT_ADDR   0x8
> +#define LAST_EXITED_AT_ADDR0x10
> +#define ACCUMULATED_ADDR   0x18
> +#define CLIENT_VOTES_ADDR  0x1c
> +
> +#define STAT_OFFSET(record_no, type) (((record_no)*(sizeof(struct 
> sleep_stats))) + (type))
> +#define APPENDED_STAT_OFFSET(record_no) ((record_no)*(sizeof(struct 
> appended_stats)))
> +
> +struct subsystem_data {
> +   const char *name;
> +   u32 smem_item;
> +   u32 pid;
> +};
> +
> +static const struct subsystem_data subsystems[] = {
> +   { "modem", 605, 1 },
> +   { "adsp", 606, 2 },
> +   { "cdsp", 607, 5 },
> +   { "slpi", 608, 3 },
> +   { "gpu", 609, 0 },
> +   { "display", 610, 0 },
> +   { "adsp_island", 613, 2 },
> +   { "slpi_island", 613, 3 },
> +};
> +
> +struct stats_config {
> +   u32 offset_addr;
> +   u32 num_records;

size_t?

> +   bool appended_stats_avail;
> +};
> +
> +struct stats_prv_data {
> +   bool appended_stats_avail;
> +   void __iomem *reg;
> +};
> +
> +struct sleep_stats {
> +   u32 stat_type;
> +   u32 count;
> +   u64 last_entered_at;
> +   u64 last_exited_at;
> +   u64 accumulated;
> +};
> +
> +struct appended_stats {
> +   u32 client_votes;
> +   u32 reserved[3];
> +};
> +
> +static void print_sleep_stats(struct seq_file *s, const struct sleep_stats 
> *stat)
> +{
> +   u64 accumulated = stat->accumulated;
> +   /*
> +* If a subsystem is in sleep when reading the sleep stats adjust
> +* the accumulated sleep duration to show actual sleep time.
> +*/
> +   if (stat->last_entered_at > stat->last_exited_at)
> +   accumulated += arch_timer_read_counter()
> +  - stat->last_entered_at;
> +
> +   seq_printf(s, "Count = %u\n", stat->count);
> +   seq_printf(s, "Last Entered At = %llu\n", stat->last_entered_at);
> +   seq_printf(s, "Last Exited At = %llu\n", stat->last_exited_at);
> +   seq_printf(s, "Accumulated Duration = %llu\n", accumulated);
> +}
> +
> +static int subsystem_sleep_stats_show(struct seq_file *s, void *d)
> +{
> +   struct subsystem_data *subsystem = s->private;
> +   struct sleep_stats *stat;
> +
> +   /*
> +* Saving this pointer during probe may not help in cases like
> +* subsystem restart, beside not each subsystem is a remote processor

s/beside/besides/
s/each/every/

> +* for e.g display for which we can get start and stop notification

for example
s/notification/notification./

> +*
> +* Lookup smem pointer each time to keep it simple.
> +*/
> +   stat = qcom_smem_get(subsystem->pid, subsystem->smem_item, NULL);
> +   if (IS_ERR(stat))
> +   return PTR_ERR(stat);
> +
> +   print_sleep_stats(s, stat);
> +
> +   return 0;
> +}
> +
> +static int soc_sleep_stats_show(struct seq_file *s, void *d)
> +{
> +   struct stats_prv_data *prv_data = s->private;
> +   void __iomem *reg = prv_data->reg;
> +   struct sleep_stats stat;
> +
> +   stat.count = readl(reg + COUNT_ADDR);
> +   stat.last_entered_at = readq(reg + LAST_ENTERED_AT_ADDR);
> +   stat.last_exited_at = readq(reg + LAST_EXITED_AT_ADDR);
> +   stat.accumulated = readq(reg + ACCUMULATED_ADDR);
> +
> +

Re: [PATCH v6 1/4] dt-bindings: Introduce SoC sleep stats bindings

2021-02-08 Thread Stephen Boyd

Quoting Maulik Shah (2021-02-04 06:21:45)
> +
> +description:
> +  Always On Processor/Resource Power Manager maintains statistics of the SoC
> +  sleep modes involving powering down of the rails and oscillator clock.
> +
> +  Statistics includes SoC sleep mode type, number of times low power mode 
> were
> +  entered, time of last entry, time of last exit and accumulated sleep 
> duration.
> +
> +properties:
> +  compatible:
> +enum:
> +  - qcom,rpmh-sleep-stats
> +  - qcom,rpm-sleep-stats
> +
> +  reg:
> +maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +examples:
> +  # Example of rpmh sleep stats
> +  - |
> +rpmh-sleep-stats@c3f {
> +  compatible = "qcom,rpmh-sleep-stats";
> +  reg = <0 0x0c3f 0 0x400>;
> +};

Maybe it should just be another reg property of the rpmh or rpm node?
Then the rpmh driver can create the stats "device" at driver probe time,
or just roll it into the same thing. It looks pretty weird to have a
device in DT for this given that it's not really hardware, more like a
place that the processor writes some stuff about what's going on in the
SoC related to power management. 

> +  # Example of rpm sleep stats
> +  - |
> +rpm-sleep-stats@469 {
> +  compatible = "qcom,rpm-sleep-stats";
> +  reg = <0 0x0469 0 0x400>;
> +};
> +...

Re: [PATCH v6 3/4] spmi: mediatek: Add support for MT6873/8192

2021-02-08 Thread Stephen Boyd

Quoting Hsin-Hsiung Wang (2021-02-06 21:19:13)
> diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
> index a53bad541f1a..418848840999 100644
> --- a/drivers/spmi/Kconfig
> +++ b/drivers/spmi/Kconfig
> @@ -25,4 +25,13 @@ config SPMI_MSM_PMIC_ARB
>   This is required for communicating with Qualcomm PMICs and
>   other devices that have the SPMI interface.
>  
> +config SPMI_MTK_PMIF
> +   tristate "Mediatek SPMI Controller (PMIC Arbiter)"
> +   help
> + If you say yes to this option, support will be included for the
> + built-in SPMI PMIC Arbiter interface on Mediatek family
> + processors.
> +
> + This is required for communicating with Mediatek PMICs and
> + other devices that have the SPMI interface.

Preferably add another newline here to unstick the 'endif'

>  endif
> diff --git a/drivers/spmi/spmi-mtk-pmif.c b/drivers/spmi/spmi-mtk-pmif.c
> new file mode 100644
> index ..4ac4643f89f3
> --- /dev/null
> +++ b/drivers/spmi/spmi-mtk-pmif.c
> @@ -0,0 +1,488 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2021 MediaTek Inc.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SWINF_IDLE 0x00
> +#define SWINF_WFVLDCLR 0x06
> +
> +#define GET_SWINF(x)   (((x) >> 1) & 0x7)
> +
> +#define PMIF_CMD_REG_0 0
> +#define PMIF_CMD_REG   1
> +#define PMIF_CMD_EXT_REG   2
> +#define PMIF_CMD_EXT_REG_LONG  3
> +
> +#define PMIF_DELAY_US   10
> +#define PMIF_TIMEOUT_US (10 * 1000)
> +
> +#define PMIF_CHAN_OFFSET 0x5
> +
> +#define PMIF_MAX_CLKS  3
> +
> +#define SPMI_OP_ST_BUSY 1
> +
> +struct ch_reg {
> +   u32 ch_sta;
> +   u32 wdata;
> +   u32 rdata;
> +   u32 ch_send;
> +   u32 ch_rdy;
> +};
> +
> +struct pmif_data {
> +   const u32   *regs;
> +   const u32   *spmimst_regs;
> +   u32 soc_chan;

Is this used?

> +};
> +
> +struct pmif {
> +   void __iomem*base;
> +   void __iomem*spmimst_base;
> +   raw_spinlock_t  lock;

Why is the spinlock raw? Is it used in hard irq handling?

> +   struct ch_reg   chan;
> +   struct clk_bulk_data clks[PMIF_MAX_CLKS];
> +   u32 nclks;
> +   const struct pmif_data *data;
> +};
> +
> +static const char * const pmif_clock_names[] = {
> +   "pmif_sys_ck", "pmif_tmr_ck", "spmimst_clk_mux",
> +};
> +
> +enum pmif_regs {
> +   PMIF_INIT_DONE,
> +   PMIF_INF_EN,
> +   PMIF_ARB_EN,
> +   PMIF_CMDISSUE_EN,
> +   PMIF_TIMER_CTRL,
> +   PMIF_SPI_MODE_CTRL,
> +   PMIF_IRQ_EVENT_EN_0,
> +   PMIF_IRQ_FLAG_0,
> +   PMIF_IRQ_CLR_0,
> +   PMIF_IRQ_EVENT_EN_1,
> +   PMIF_IRQ_FLAG_1,
> +   PMIF_IRQ_CLR_1,
> +   PMIF_IRQ_EVENT_EN_2,
> +   PMIF_IRQ_FLAG_2,
> +   PMIF_IRQ_CLR_2,
> +   PMIF_IRQ_EVENT_EN_3,
> +   PMIF_IRQ_FLAG_3,
> +   PMIF_IRQ_CLR_3,
> +   PMIF_IRQ_EVENT_EN_4,
> +   PMIF_IRQ_FLAG_4,
> +   PMIF_IRQ_CLR_4,
> +   PMIF_WDT_EVENT_EN_0,
> +   PMIF_WDT_FLAG_0,
> +   PMIF_WDT_EVENT_EN_1,
> +   PMIF_WDT_FLAG_1,
> +   PMIF_SWINF_0_STA,
> +   PMIF_SWINF_0_WDATA_31_0,
> +   PMIF_SWINF_0_RDATA_31_0,
> +   PMIF_SWINF_0_ACC,
> +   PMIF_SWINF_0_VLD_CLR,
> +   PMIF_SWINF_1_STA,
> +   PMIF_SWINF_1_WDATA_31_0,
> +   PMIF_SWINF_1_RDATA_31_0,
> +   PMIF_SWINF_1_ACC,
> +   PMIF_SWINF_1_VLD_CLR,
> +   PMIF_SWINF_2_STA,
> +   PMIF_SWINF_2_WDATA_31_0,
> +   PMIF_SWINF_2_RDATA_31_0,
> +   PMIF_SWINF_2_ACC,
> +   PMIF_SWINF_2_VLD_CLR,
> +   PMIF_SWINF_3_STA,
> +   PMIF_SWINF_3_WDATA_31_0,
> +   PMIF_SWINF_3_RDATA_31_0,
> +   PMIF_SWINF_3_ACC,
> +   PMIF_SWINF_3_VLD_CLR,
> +};
> +
> +static const u32 mt6873_regs[] = {
> +   [PMIF_INIT_DONE] =  0x,
> +   [PMIF_INF_EN] = 0x0024,
> +   [PMIF_ARB_EN] = 0x0150,
> +   [PMIF_CMDISSUE_EN] =0x03B4,
> +   [PMIF_TIMER_CTRL] = 0x03E0,
> +   [PMIF_SPI_MODE_CTRL] =  0x0400,
> +   [PMIF_IRQ_EVENT_EN_0] = 0x0418,
> +   [PMIF_IRQ_FLAG_0] = 0x0420,
> +   [PMIF_IRQ_CLR_0] =  0x0424,
> +   [PMIF_IRQ_EVENT_EN_1] = 0x0428,
> +   [PMIF_IRQ_FLAG_1] = 0x0430,
> +   [PMIF_IRQ_CLR_1] =  0x0434,
> +   [PMIF_IRQ_EVENT_EN_2] = 0x0438,
> +   [PMIF_IRQ_FLAG_2] = 0x0440,
> +   [PMIF_IRQ_CLR_2] =  0x0444,
> +   [PMIF_IRQ_EVENT_EN_3] = 0x0448,
> +   [PMIF_IRQ_FLAG_3] = 0x0450,
> +   [PMIF_IRQ_CLR_3] =  0x0454,
> +   [PMIF_IRQ_EVENT_EN_4] = 0x0458,
> +   [PMIF_IRQ_FLAG_4] = 0x0460,
> +   [PMIF_IRQ_CLR_4] =  0x0464,
> +   [PMIF_WDT_EVENT_EN_0] = 0x046C,
> +   [PMIF_WDT_FLAG_0] = 0x0470,
> +   [PMIF_WDT_EVENT_EN_1] = 0x0474,
> +   [PMIF_WDT_FLAG_1] = 0x0478,
> +   [PMIF_SWINF_0_ACC] =0x0C00,
> +   [PMIF_SWINF_0_WDATA_31_0] = 0x0C04,
> +   [PMIF_SWINF_0_RDATA_31_0] = 0x0C14,
> +

Re: [PATCH v8 11/14] spmi: hisi-spmi-controller: move driver from staging

2021-02-08 Thread Stephen Boyd

Quoting Mauro Carvalho Chehab (2021-01-29 11:51:57)
> The Hisilicon 6421v600 SPMI driver is ready for mainstream.
> 
> So, move it from staging.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---

Acked-by: Stephen Boyd 

Rob had some comments on the binding that don't look to be addressed
though so I'd prefer we get the binding into shape before graduating
this driver from staging.

Re: [PATCH] spmi: spmi-pmic-arb: Fix hw_irq overflow

2021-02-08 Thread Stephen Boyd

Quoting Subbaraman Narayanamurthy (2021-02-08 11:33:04)
> Currently, when handling the SPMI summary interrupt, the hw_irq
> number is calculated based on SID, Peripheral ID, IRQ index and
> APID. This is then passed to irq_find_mapping() to see if a
> mapping exists for this hw_irq and if available, invoke the
> interrupt handler. Since the IRQ index uses an "int" type, hw_irq
> which is of unsigned long data type can take a large value when
> SID has its MSB set to 1 and the type conversion happens. Because
> of this, irq_find_mapping() returns 0 as there is no mapping
> for this hw_irq. This ends up invoking cleanup_irq() as if
> the interrupt is spurious whereas it is actually a valid
> interrupt. Fix this by using the proper data type (u32) for id.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Subbaraman Narayanamurthy 
> ---

Applied to spmi-next

Re: [PATCH v7 02/14] clk: tegra: Don't enable PLLE HW sequencer at init

2021-02-08 Thread Stephen Boyd

Quoting JC Kuo (2021-01-19 23:34:02)
> PLLE hardware power sequencer references PEX/SATA UPHY PLL hardware
> power sequencers' output to enable/disable PLLE. PLLE hardware power
> sequencer has to be enabled only after PEX/SATA UPHY PLL's sequencers
> are enabled.
> 
> Signed-off-by: JC Kuo 
> Acked-by: Thierry Reding 
> ---

Acked-by: Stephen Boyd

Re: [PATCH] MAINTAINERS: Add section for NXP i.MX clock drivers

2021-02-08 Thread Stephen Boyd

Quoting Abel Vesa (2021-01-13 04:53:08)
> Add a section for NXP i.MX clock drivers and list myself
> as the maintainer.
> 
> Signed-off-by: Abel Vesa 
> ---

Applied to clk-next

Re: [PATCH v7 01/14] clk: tegra: Add PLLE HW power sequencer control

2021-02-08 Thread Stephen Boyd

Quoting JC Kuo (2021-01-19 23:34:01)
> PLLE has a hardware power sequencer logic which is a state machine
> that can power on/off PLLE without any software intervention. The
> sequencer has two inputs, one from XUSB UPHY PLL and the other from
> SATA UPHY PLL. PLLE provides reference clock to XUSB and SATA UPHY
> PLLs. When both of the downstream PLLs are powered-off, PLLE hardware
> power sequencer will automatically power off PLLE for power saving.
> 
> XUSB and SATA UPHY PLLs also have their own hardware power sequencer
> logic. XUSB UPHY PLL is shared between XUSB SuperSpeed ports and PCIE
> controllers. The XUSB UPHY PLL hardware power sequencer has inputs
> from XUSB and PCIE. When all of the XUSB SuperSpeed ports and PCIE
> controllers are in low power state, XUSB UPHY PLL hardware power
> sequencer automatically power off PLL and flags idle to PLLE hardware
> power sequencer. Similar applies to SATA UPHY PLL.
> 
> PLLE hardware power sequencer has to be enabled after both downstream
> sequencers are enabled.
> 
> This commit adds two helper functions:
> 1. tegra210_plle_hw_sequence_start() for XUSB PADCTL driver to enable
>PLLE hardware sequencer at proper time.
> 
> 2. tegra210_plle_hw_sequence_is_enabled() for XUSB PADCTL driver to
>check whether PLLE hardware sequencer has been enabled or not.
> 
> Signed-off-by: JC Kuo 
> Acked-by: Thierry Reding 
> ---

Acked-by: Stephen Boyd

Re: [PATCH v2 1/5] clk: sunxi-ng: mp: fix parent rate change flag check

2021-02-08 Thread Stephen Boyd

Quoting Jernej Skrabec (2021-02-08 04:17:48)
> CLK_SET_RATE_PARENT flag is checked on parent clock instead of current
> one. Fix that.
> 
> Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when 
> allowed")
> Reviewed-by: Chen-Yu Tsai 
> Tested-by: Andre Heider 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/clk/sunxi-ng/ccu_mp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c
> index fa4ecb915590..5f40be6d2dfd 100644
> --- a/drivers/clk/sunxi-ng/ccu_mp.c
> +++ b/drivers/clk/sunxi-ng/ccu_mp.c
> @@ -108,7 +108,7 @@ static unsigned long ccu_mp_round_rate(struct 
> ccu_mux_internal *mux,
> max_m = cmp->m.max ?: 1 << cmp->m.width;
> max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
>  
> -   if (!(clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT)) {
> +   if (!(clk_hw_get_flags(>common.hw) & CLK_SET_RATE_PARENT)) {

This is also clk_hw_can_set_rate_parent()

> ccu_mp_find_best(*parent_rate, rate, max_m, max_p, , );
> rate = *parent_rate / p / m;
> } else {

Re: [PATCH] drm/msm/dp: Add a missing semi-colon

2021-02-08 Thread Stephen Boyd

Quoting Joe Perches (2021-02-06 21:06:54)
> On Sat, 2021-02-06 at 20:18 -0800, Stephen Boyd wrote:
> > A missing semicolon here causes my external display to stop working.
> > Indeed, missing the semicolon on the return statement leads to
> > dp_panel_update_tu_timings() not existing because the compiler thinks
> > it's part of the return statement of a void function, so it must not be
> > important.
> > 
> >   $ ./scripts/bloat-o-meter before.o after.o
> >   add/remove: 1/1 grow/shrink: 0/1 up/down: 7400/-7540 (-140)
> >   Function old new   delta
> >   dp_panel_update_tu_timings -7400   +7400
> >   _dp_ctrl_calc_tu.constprop 18024   17900-124
> >   dp_panel_update_tu_timings.constprop7416   -   -7416
> >   Total: Before=54440, After=54300, chg -0.26%
> > 
> > Add a semicolon so this function works like it used to.
> []
> > diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c 
> > b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> []
> > @@ -631,7 +631,7 @@ static void _dp_ctrl_calc_tu(struct dp_tu_calc_input 
> > *in,
> >  
> > 
> >   tu = kzalloc(sizeof(*tu), GFP_KERNEL);
> >   if (!tu)
> > - return
> > + return;
> >  
> > 
> >   dp_panel_update_tu_timings(in, tu);
> 
> Wow, that's really unfortunate that dp_panel_update_tu_timings
> is also void.
> 
> Perhaps this as YA checkpatch warning:
> 
> ---

Acked-by: Stephen Boyd

Re: [PATCH v2 11/11] clk: qcom: gpucc-msm8998: Allow fabia gpupll0 rate setting

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:59)
> The GPU PLL0 is not a fixed PLL and the rate can be set on it:
> this is necessary especially on boards which bootloader is setting
> a very low rate on this PLL before booting Linux, which would be
> unsuitable for postdividing to reach the maximum allowed Adreno GPU
> frequency of 710MHz (or, actually, even 670MHz..) on this SoC.
> 
> To allow setting rates on the GPU PLL0, also define VCO boundaries
> and set the CLK_SET_RATE_PARENT flag to the GPU PLL0 postdivider.
> 
> With this change, the Adreno GPU is now able to scale through all
> the available frequencies.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---

Applied to clk-next

Re: [PATCH v2 11/11] clk: qcom: gpucc-msm8998: Allow fabia gpupll0 rate setting

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:59)
> The GPU PLL0 is not a fixed PLL and the rate can be set on it:
> this is necessary especially on boards which bootloader is setting
> a very low rate on this PLL before booting Linux, which would be
> unsuitable for postdividing to reach the maximum allowed Adreno GPU
> frequency of 710MHz (or, actually, even 670MHz..) on this SoC.
> 
> To allow setting rates on the GPU PLL0, also define VCO boundaries
> and set the CLK_SET_RATE_PARENT flag to the GPU PLL0 postdivider.
> 
> With this change, the Adreno GPU is now able to scale through all
> the available frequencies.

BTW, you're probably undervolting your GPU and clocking it higher
than it should be at the voltage from boot.

> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  drivers/clk/qcom/gpucc-msm8998.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/qcom/gpucc-msm8998.c 
> b/drivers/clk/qcom/gpucc-msm8998.c
> index 1a518c4915b4..fedfffaf0a8d 100644
> --- a/drivers/clk/qcom/gpucc-msm8998.c
> +++ b/drivers/clk/qcom/gpucc-msm8998.c
> @@ -50,6 +50,11 @@ static struct clk_branch gpucc_cxo_clk = {
> },
>  };
>  
> +static struct pll_vco fabia_vco[] = {

Should be const.

> +   { 24960, 20, 0 },
> +   { 12500, 10, 1 },
> +};
> +
>  static const struct clk_div_table post_div_table_fabia_even[] = {
> { 0x0, 1 },
> { 0x1, 2 },

Re: [PATCH v2 10/11] clk: qcom: gpucc-msm8998: Add resets, cxc, fix flags on gpu_gx_gdsc

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:58)
> The GPU GX GDSC has GPU_GX_BCR reset and gfx3d_clk CXC, as stated
> on downstream kernels (and as verified upstream, because otherwise
> random lockups happen).
> Also, add PWRSTS_RET and NO_RET_PERIPH: also as found downstream,
> and also as verified here, to avoid GPU related lockups it is
> necessary to force retain mem, but *not* peripheral when enabling
> this GDSC (and, of course, the inverse on disablement).
> 
> With this change, the GPU finally works flawlessly on my four
> different MSM8998 devices from two different manufacturers.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---

Applied to clk-next

Re: [PATCH v2 09/11] clk: qcom: mmcc-msm8998: Set bimc_smmu_gdsc always on

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:57)
> This GDSC enables (or cuts!) power to the Multimedia Subsystem IOMMU
> (mmss smmu), which has bootloader pre-set secure contexts.
> In the event of a complete power loss, the secure contexts will be
> reset and the hypervisor will crash the SoC.
> 
> To prevent this, and get a working multimedia subsystem, set this
> GDSC as always on.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---

Applied to clk-next

Re: [PATCH v2 08/11] clk: qcom: mmcc-msm8998: Add hardware clockgating registers to some clks

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:56)
> Hardware clock gating is supported on some of the clocks declared in
> there: ignoring that it does exist may lead to unstabilities on some
> firmwares.
> Add the HWCG registers where applicable to stop potential crashes.
> 
> This was verified on a smartphone shipped with a recent MSM8998
> firmware, which will experience random crashes without this change.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---

Applied to clk-next

Re: [PATCH v2 07/11] clk: qcom: mmcc-msm8998: Set CLK_GET_RATE_NOCACHE to pixel/byte clks

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:55)
> The pixel and byte clocks rate should not be cached, as a VCO shutdown
> may clear the frequency setup and this may not be set again due to the
> cached rate being present.
> This will also be useful when shadow clocks will be implemented in
> the DSI PLL for seamless timing/resolution switch.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  drivers/clk/qcom/mmcc-msm8998.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

We didn't do this on sdm845, so I'm not going to apply this patch. The
rate caching thing is a problem with the display driver that should be
fixed some other way vs. setting nocache here.

Re: [PATCH v2 07/11] clk: qcom: mmcc-msm8998: Set CLK_GET_RATE_NOCACHE to pixel/byte clks

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:55)
> The pixel and byte clocks rate should not be cached, as a VCO shutdown
> may clear the frequency setup and this may not be set again due to the
> cached rate being present.
> This will also be useful when shadow clocks will be implemented in
> the DSI PLL for seamless timing/resolution switch.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---

Applied to clk-next

Re: [PATCH v2 05/11] clk: qcom: gcc-msm8998: Mark gpu_cfg_ahb_clk as critical

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:53)
> The GPU IOMMU depends on this clock and the hypervisor will crash
> the SoC if this clock gets disabled because the secure contexts
> that have been set on this IOMMU by the bootloader will become
> unaccessible (or they get reset).
> Mark this clock as critical to avoid this issue when the Adreno
> GPU is enabled.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---

Applied to clk-next

Re: [PATCH v2 06/11] clk: qcom: gcc-msm8998: Fix Alpha PLL type for all GPLLs

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:54)
> All of the GPLLs in the MSM8998 Global Clock Controller are Fabia PLLs
> and not generic alphas: this was producing bad effects over the entire
> clock tree of MSM8998, where any GPLL child clock was declaring a false
> clock rate, due to their parent also showing the same.
> 
> The issue resides in the calculation of the clock rate for the specific
> Alpha PLL type, where Fabia has a different register layout; switching
> the MSM8998 GPLLs to the correct Alpha Fabia PLL type fixes the rate
> (calculation) reading. While at it, also make these PLLs fixed since
> their rate is supposed to *never* be changed while the system runs, as
> this would surely crash the entire SoC.
> 
> Now all the children of all the PLLs are also complying with their
> specified clock table and system stability is improved.
> 
> Fixes: b5f5f525c547 ("clk: qcom: Add MSM8998 Global Clock Control (GCC) 
> driver")
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---

Applied to clk-next

Re: [PATCH v2 04/11] clk: qcom: gcc-msm8998: Add missing hmss_gpll0_clk_src clock

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:52)
> To achieve CPR-Hardened functionality this clock must be on: add it
> in order to be able to get it managed by the CPR3 driver.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---

Applied to clk-next

Re: [PATCH v2 03/11] dt-bindings: clock: gcc-msm8998: Add HMSS_GPLL0_CLK_SRC definition

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:51)
> Add new clock definition to gcc-msm8998 dt-bindings
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---

Applied to clk-next

Re: [PATCH v2 02/11] clk: qcom: gcc-msm8998: Wire up gcc_mmss_gpll0 clock

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:50)
> This clock enables the GPLL0 output to the multimedia subsystem
> clock controller.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---

Applied to clk-next

Re: [PATCH v2 01/11] dt-bindings: clocks: gcc-msm8998: Add GCC_MMSS_GPLL0_CLK definition

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:49)
> Add new clock definition to gcc-msm8998 dt-bindings.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---

Applied to clk-next

Re: [PATCH v2 05/11] clk: qcom: gcc-msm8998: Mark gpu_cfg_ahb_clk as critical

2021-02-08 Thread Stephen Boyd

Quoting AngeloGioacchino Del Regno (2021-01-14 14:10:53)
> The GPU IOMMU depends on this clock and the hypervisor will crash
> the SoC if this clock gets disabled because the secure contexts
> that have been set on this IOMMU by the bootloader will become
> unaccessible (or they get reset).
> Mark this clock as critical to avoid this issue when the Adreno
> GPU is enabled.
> 
> Signed-off-by: AngeloGioacchino Del Regno 
> 
> ---
>  drivers/clk/qcom/gcc-msm8998.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/clk/qcom/gcc-msm8998.c b/drivers/clk/qcom/gcc-msm8998.c
> index c8d4c0348952..afea60a3ef43 100644
> --- a/drivers/clk/qcom/gcc-msm8998.c
> +++ b/drivers/clk/qcom/gcc-msm8998.c
> @@ -2081,6 +2081,12 @@ static struct clk_branch gcc_gpu_cfg_ahb_clk = {
> .hw.init = &(struct clk_init_data){
> .name = "gcc_gpu_cfg_ahb_clk",
> .ops = _branch2_ops,
> +   /*
> +* The GPU IOMMU depends on this clock and hypervisor
> +* will crash the SoC if this clock goes down, due to
> +* secure contexts protection.
> +*/
> +   .flags = CLK_IS_CRITICAL,
> },
> },

Please send a followup patch that hits the branch on at probe time and
removes this clk from the kernel. That will save some memory and
overhead of worrying about this clk.

Re: [PATCH] clk: qcom: smd-rpm: Add mdm9607 clocks

2021-02-08 Thread Stephen Boyd

Quoting Konrad Dybcio (2021-01-30 17:30:09)
> Add support for RPM-managed clocks on the MDM9607 platform.
> 
> Signed-off-by: Konrad Dybcio 
> ---
>  .../devicetree/bindings/clock/qcom,rpmcc.txt  |  1 +
>  drivers/clk/qcom/clk-smd-rpm.c| 32 +++
>  2 files changed, 33 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt 
> b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> index b44a0622fb3a..5ac207d4b8ab 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> @@ -10,6 +10,7 @@ Required properties :
>  - compatible : shall contain only one of the following. The generic
> compatible "qcom,rpmcc" should be also included.
>  
> +   "qcom,rpmcc-mdm9607", "qcom,rpmcc"
> "qcom,rpmcc-msm8660", "qcom,rpmcc"
> "qcom,rpmcc-apq8060", "qcom,rpmcc"
> "qcom,rpmcc-msm8916", "qcom,rpmcc"
> diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/drivers/clk/qcom/clk-smd-rpm.c
> index 0e1dfa89489e..ceea50bae8f8 100644
> --- a/drivers/clk/qcom/clk-smd-rpm.c
> +++ b/drivers/clk/qcom/clk-smd-rpm.c
> @@ -406,6 +406,37 @@ static const struct clk_ops clk_smd_rpm_branch_ops = {
> .unprepare  = clk_smd_rpm_unprepare,
>  };
>  
> +/* mdm9607 */
> +DEFINE_CLK_SMD_RPM_BRANCH(mdm9607, xo_clk_src, xo_a_clk_src, 
> QCOM_SMD_RPM_MISC_CLK, 0,
> +   1920);

Same comment about the parent rate being specified here. Please follow
how clk-rpmh has done it.

> +DEFINE_CLK_SMD_RPM(mdm9607, pcnoc_clk, pcnoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 0);

Re: [PATCH v5 1/5] clk: qcom: clk-alpha-pll: replace regval with val

2021-02-08 Thread Stephen Boyd

Quoting Vinod Koul (2021-01-26 23:08:07)
> Driver uses regval variable for holding register values, replace with a
> shorter one val
> 
> Suggested-by: Stephen Boyd 
> Reviewed-by: Bjorn Andersson 
> Signed-off-by: Vinod Koul 
> ---

Applied to clk-next

Re: [PATCH v5 5/5] clk: qcom: gcc: Add clock driver for SM8350

2021-02-08 Thread Stephen Boyd

Quoting Vinod Koul (2021-01-26 23:08:11)
> From: Vivek Aknurwar 
> 
> This adds Global Clock controller (GCC) driver for SM8350 SoC
> 
> Signed-off-by: Vivek Aknurwar 
> Signed-off-by: Jeevan Shriram 
> [vkoul: rebase and tidy up for upstream]
> Signed-off-by: Vinod Koul 
> Reviewed-by: Bjorn Andersson 
> ---

Applied to clk-next

Re: [PATCH v5 3/5] clk: qcom: clk-alpha-pll: Add support for Lucid 5LPE PLL

2021-02-08 Thread Stephen Boyd

Quoting Vinod Koul (2021-01-26 23:08:09)
> From: Vivek Aknurwar 
> 
> Lucid 5LPE is a slightly different Lucid PLL with different offsets and
> porgramming sequence so add support for these
> 
> Signed-off-by: Vivek Aknurwar 
> Signed-off-by: Jeevan Shriram 
> [vkoul: rebase and tidy up for upstream]
> Signed-off-by: Vinod Koul 
> Reviewed-by: AngeloGioacchino Del Regno 
> 
> Reviewed-by: Bjorn Andersson 
> ---

Applied to clk-next

Re: [PATCH v5 2/5] clk: qcom: clk-alpha-pll: modularize alpha_pll_trion_set_rate()

2021-02-08 Thread Stephen Boyd

Quoting Vinod Koul (2021-01-26 23:08:08)
> Trion 5LPE set rate uses code similar to alpha_pll_trion_set_rate() but
> with different registers. Modularize these by moving out latch and latch
> ack bits so that we can reuse the function.
> 
> Suggested-by: AngeloGioacchino Del Regno 
> 
> Reviewed-by: Bjorn Andersson 
> Signed-off-by: Vinod Koul 
> ---

Applied to clk-next

Re: [PATCH v5 4/5] dt-bindings: clock: Add SM8350 GCC clock bindings

2021-02-08 Thread Stephen Boyd

Quoting Vinod Koul (2021-01-26 23:08:10)
> Add device tree bindings for global clock controller on SM8350 SoCs.
> 
> Reviewed-by: Rob Herring 
> Reviewed-by: Bjorn Andersson 
> Signed-off-by: Vinod Koul 
> ---

Applied to clk-next

Re: [PATCH v2 2/2] clk: qcom: gcc: Add global clock controller driver for SC8180x

2021-02-08 Thread Stephen Boyd

Quoting Bjorn Andersson (2021-01-25 20:31:55)
> Add clocks, resets and some of the GDSC provided by the global clock
> controller found in the Qualcomm SC8180x platform.
> 
> Signed-off-by: Bjorn Andersson 
> ---

Applied to clk-next

< 1 2 3 4 5 6 7 8 9 10 >

401 - 500 of 16585 matches

Mail list logo