Rid W=1 warnings from Clock
Subsystems (18)
cover Rid W=1 warnings from Clock
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings.
This is the last set. Clock is clean after this.
Lee Jones (21):
clk: zynq: pll: Fix kernel-doc formatting in 'clk_register_zynq_pll's
header
clk: ti: clkt_dpll: Fix some kernel-doc misdemeanours
clk: ti: dpll3xxx: Fix some kernel-doc headers and promote other
worthy ones
clk: qcom: clk-regmap: Provide missing description for
'devm_clk_register_regmap()'s dev param
clk: sunxi: clk-sun9i-core: Demote non-conformant kernel-doc headers
clk: sunxi: clk-usb: Demote obvious kernel-doc abuse
clk: tegra: clk-tegra30: Remove unused variable 'reg'
clk: clkdev: Ignore suggestion to use gnu_printf() as it's not
appropriate here
clk: tegra: cvb: Provide missing description for
'tegra_cvb_add_opp_table()'s align param
clk: ti: dpll44xx: Fix some potential doc-rot
clk: renesas: renesas-cpg-mssr: Fix formatting issues for
'smstpcr_saved's documentation
clk: sunxi: clk-sun6i-ar100: Demote non-conformant kernel-doc header
clk: qcom: gcc-ipq4019: Remove unused variable 'ret'
clk: clk-fixed-mmio: Demote obvious kernel-doc abuse
clk: clk-npcm7xx: Remove unused static const tables 'npcm7xx_gates'
and 'npcm7xx_divs_fx'
clk: qcom: mmcc-msm8974: Remove unused static const tables
'mmcc_xo_mmpll0_1_2_gpll0{map}'
clk: clk-xgene: Add description for 'mask' and fix formatting for
'flags' clk: qcom: clk-rpm: Remove a bunch of superfluous code
clk: spear: Move prototype to accessible header
clk: imx: Move 'imx6sl_set_wait_clk()'s prototype out to accessible
header
clk: zynqmp: divider: Add missing description for 'max_div'
arch/arm/mach-imx/common.h | 1 - arch/arm/mach-imx/cpuidle-imx6sl.c | 1 + arch/arm/mach-imx/pm-imx6.c | 1 + arch/arm/mach-spear/generic.h | 12 --- arch/arm/mach-spear/spear13xx.c | 1 + drivers/clk/clk-fixed-mmio.c | 2 +- drivers/clk/clk-npcm7xx.c | 108 ------------------------- drivers/clk/clk-xgene.c | 5 +- drivers/clk/clkdev.c | 7 ++ drivers/clk/imx/clk-imx6sl.c | 1 + drivers/clk/qcom/clk-regmap.c | 1 + drivers/clk/qcom/clk-rpm.c | 63 --------------- drivers/clk/qcom/gcc-ipq4019.c | 7 +- drivers/clk/qcom/mmcc-msm8974.c | 16 ---- drivers/clk/renesas/renesas-cpg-mssr.c | 4 +- drivers/clk/spear/spear1310_clock.c | 1 + drivers/clk/spear/spear1340_clock.c | 1 + drivers/clk/sunxi/clk-sun6i-ar100.c | 2 +- drivers/clk/sunxi/clk-sun9i-core.c | 8 +- drivers/clk/sunxi/clk-usb.c | 2 +- drivers/clk/tegra/clk-tegra30.c | 5 +- drivers/clk/tegra/cvb.c | 1 + drivers/clk/ti/clkt_dpll.c | 3 +- drivers/clk/ti/dpll3xxx.c | 20 ++--- drivers/clk/ti/dpll44xx.c | 6 +- drivers/clk/zynq/pll.c | 12 +-- drivers/clk/zynqmp/divider.c | 1 + include/linux/clk/imx.h | 15 ++++ include/linux/clk/spear.h | 23 ++++++ 29 files changed, 92 insertions(+), 238 deletions(-) create mode 100644 include/linux/clk/imx.h create mode 100644 include/linux/clk/spear.h
Signature · 1 line
2.25.1
PATCH 1/21 clk: zynq: pll: Fix kernel-doc formatting in 'clk_register_zynq_pll's header
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'
--- drivers/clk/zynq/pll.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/clk/zynq/pll.c +6 -6
@@ -173,12 +173,12 @@ static const struct clk_ops zynq_pll_ops = {/** * clk_register_zynq_pll() - Register PLL with the clock framework -* @name PLL name -* @parent Parent clock name -* @pll_ctrl Pointer to PLL control register -* @pll_status Pointer to PLL status register -* @lock_index Bit index to this PLL's lock status bit in @pll_status -* @lock Register lock +* @name: PLL name +* @parent: Parent clock name +* @pll_ctrl: Pointer to PLL control register +* @pll_status: Pointer to PLL status register +* @lock_index: Bit index to this PLL's lock status bit in @pll_status +* @lock: Register lock * Returns handle to the registered clock. */ struct clk *clk_register_zynq_pll(const char *name, const char *parent,
Signature · 7 lines
2.25.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 01/21] clk: zynq: pll: Fix kernel-doc formatting in 'clk_register_zynq_pll's header
Quoted 34 lines · Lee Jones
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 <[email protected]>Cc Stephen Boyd <[email protected]>Cc Michal Simek <[email protected]>Cc "Sören Brinkmann" <[email protected]>Signed-off-by Lee Jones <[email protected]>--- drivers/clk/zynq/pll.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)drivers/clk/zynq/pll.c +0
-5@@ -173,12 +173,12 @@ static const struct clk_ops zynq_pll_ops = {/** * clk_register_zynq_pll() - Register PLL with the clock framework -* @name PLL name -* @parent Parent clock name -* @pll_ctrl Pointer to PLL control register -* @pll_status Pointer to PLL status register -* @lock_index Bit index to this PLL's lock status bit in @pll_status
drivers/clk/zynq/pll.c static const struct clk_ops zynq_pll_ops = { · line 184
Quoted 10 lines
drivers/clk/zynq/pll.c +6
-1-* @lock Register lock +* @name: PLL name +* @parent: Parent clock name +* @pll_ctrl: Pointer to PLL control register +* @pll_status: Pointer to PLL status register +* @lock_index: Bit index to this PLL's lock status bit in @pll_status +* @lock: Register lock * Returns handle to the registered clock. */ struct clk *clk_register_zynq_pll(const char *name, const char *parent,
When you are on this we should also fix that Returns which are also reported by kernel-doc
When your patch is applied:
[linux](master)$ ./scripts/kernel-doc -v -man drivers/clk/zynq/pll.c > /dev/nulldrivers/clk/zynq/pll.c:15: warning: missing initial short description on line:
* struct zynq_plldrivers/clk/zynq/pll.c:15: info: Scanning doc for struct drivers/clk/zynq/pll.c:45: info: Scanning doc for zynq_pll_round_rate drivers/clk/zynq/pll.c:53: warning: No description found for return value of 'zynq_pll_round_rate'drivers/clk/zynq/pll.c:66: info: Scanning doc for zynq_pll_recalc_rate drivers/clk/zynq/pll.c:73: warning: No description found for return value of 'zynq_pll_recalc_rate'drivers/clk/zynq/pll.c:88: info: Scanning doc for zynq_pll_is_enabled drivers/clk/zynq/pll.c:96: warning: No description found for return value of 'zynq_pll_is_enabled'drivers/clk/zynq/pll.c:111: info: Scanning doc for zynq_pll_enable drivers/clk/zynq/pll.c:116: warning: No description found for return value of 'zynq_pll_enable'drivers/clk/zynq/pll.c:141: info: Scanning doc for zynq_pll_disable drivers/clk/zynq/pll.c:175: info: Scanning doc for clk_register_zynq_pll drivers/clk/zynq/pll.c:187: warning: No description found for return value of 'clk_register_zynq_pll'
6 warnings
Can you please also fix it? It can be done in separate patch if this is not reported by W=1.
Thanks,
Michal
Re: [PATCH 01/21] clk: zynq: pll: Fix kernel-doc formatting in 'clk_register_zynq_pll's header
In reply to Lee JonesQuoting Lee Jones (2021-01-26 04:45:20)
Quoted 9 lines
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'
Quoted 8 lines
Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc Michal Simek <[email protected]>Cc "Sören Brinkmann" <[email protected]>Signed-off-by Lee Jones <[email protected]>---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 2/21 clk: ti: clkt_dpll: Fix some kernel-doc misdemeanours
In reply to Lee JonesFixes 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'
--- drivers/clk/ti/clkt_dpll.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/clk/ti/clkt_dpll.c +2 -1
@@ -269,8 +269,9 @@ unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk)/** * omap2_dpll_round_rate - round a target rate for an OMAP DPLL -* @clk: struct clk * for a DPLL +* @hw: struct clk_hw containing the struct clk * for a DPLL * @target_rate: desired DPLL clock rate +* @parent_rate: parent's DPLL clock rate * * Given a DPLL and a desired target rate, round the target rate to a * possible, programmable rate for this DPLL. Attempts to select the
Signature · 1 line
2.25.1
Re: [PATCH 02/21] clk: ti: clkt_dpll: Fix some kernel-doc misdemeanours
Quoting Lee Jones (2021-01-26 04:45:21)
Quoted 6 lines
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'
Quoted 8 lines
Cc Tero Kristo <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc Richard Woodruff <[email protected]>Signed-off-by Lee Jones <[email protected]>---
Applied to clk-next
PATCH 3/21 clk: ti: dpll3xxx: Fix some kernel-doc headers and promote other worthy ones
In reply to Lee JonesFixes 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'
--- drivers/clk/ti/dpll3xxx.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-)
drivers/clk/ti/dpll3xxx.c +11 -9
@@ -125,7 +125,7 @@ static u16 _omap3_dpll_compute_freqsel(struct clk_hw_omap *clk, u8 n)return f; } -/* +/** * _omap3_noncore_dpll_lock - instruct a DPLL to lock and wait for readiness * @clk: pointer to a DPLL struct clk *
@@ -168,7 +168,7 @@ static int _omap3_noncore_dpll_lock(struct clk_hw_omap *clk)return r; } -/* +/** * _omap3_noncore_dpll_bypass - instruct a DPLL to bypass and wait for readiness * @clk: pointer to a DPLL struct clk *
@@ -204,7 +204,7 @@ static int _omap3_noncore_dpll_bypass(struct clk_hw_omap *clk)return r; } -/* +/** * _omap3_noncore_dpll_stop - instruct a DPLL to stop * @clk: pointer to a DPLL struct clk *
@@ -291,7 +291,7 @@ static void _lookup_sddiv(struct clk_hw_omap *clk, u8 *sd_div, u16 m, u8 n) *sd_div = sd; } -/* +/** * _omap3_noncore_dpll_program - set non-core DPLL M,N values directly * @clk: struct clk * of DPLL to set * @freqsel: FREQSEL value to set
@@ -406,7 +406,8 @@ static int omap3_noncore_dpll_program(struct clk_hw_omap *clk, u16 freqsel)/** * omap3_dpll_recalc - recalculate DPLL rate -* @clk: DPLL struct clk +* @hw: struct clk_hw containing the DPLL struct clk +* @parent_rate: clock rate of the DPLL parent * * Recalculate and propagate the DPLL rate. */
@@ -421,7 +422,7 @@ unsigned long omap3_dpll_recalc(struct clk_hw *hw, unsigned long parent_rate)/** * omap3_noncore_dpll_enable - instruct a DPLL to enter bypass or lock mode -* @clk: pointer to a DPLL struct clk +* @hw: struct clk_hw containing then pointer to a DPLL struct clk * * Instructs a non-CORE DPLL to enable, e.g., to enter bypass or lock. * The choice of modes depends on the DPLL's programmed rate: if it is
@@ -470,7 +471,7 @@ int omap3_noncore_dpll_enable(struct clk_hw *hw)/** * omap3_noncore_dpll_disable - instruct a DPLL to enter low-power stop -* @clk: pointer to a DPLL struct clk +* @hw: struct clk_hw containing then pointer to a DPLL struct clk * * Instructs a non-CORE DPLL to enter low-power stop. This function is * intended for use in struct clkops. No return value.
@@ -745,7 +746,8 @@ static struct clk_hw_omap *omap3_find_clkoutx2_dpll(struct clk_hw *hw)/** * omap3_clkoutx2_recalc - recalculate DPLL X2 output virtual clock rate -* @clk: DPLL output struct clk +* @hw: pointer struct clk_hw +* @parent_rate: clock rate of the DPLL parent * * Using parent clock DPLL data, look up DPLL state. If locked, set our * rate to the dpll_clk * 2; otherwise, just use dpll_clk.
@@ -913,7 +915,7 @@ const struct clk_hw_omap_ops clkhwops_omap3_dpll = {* omap3_dpll4_set_rate - set rate for omap3 per-dpll * @hw: clock to change * @rate: target rate for clock -* @parent_rate: rate of the parent clock +* @parent_rate: clock rate of the DPLL parent * * Check if the current SoC supports the per-dpll reprogram operation * or not, and then do the rate change if supported. Returns -EINVAL
Signature · 1 line
2.25.1
Re: [PATCH 03/21] clk: ti: dpll3xxx: Fix some kernel-doc headers and promote other worthy ones
Quoting Lee Jones (2021-01-26 04:45:22)
Quoted 13 lines
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'
Quoted 7 lines
Cc Tero Kristo <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Signed-off-by Lee Jones <[email protected]>---
Applied to clk-next
PATCH 4/21 clk: qcom: clk-regmap: Provide missing description for 'devm_clk_register_regmap()'s dev param
In reply to Lee JonesFixes 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'
--- drivers/clk/qcom/clk-regmap.c | 1 + 1 file changed, 1 insertion(+)
drivers/clk/qcom/clk-regmap.c +1 -0
@@ -87,6 +87,7 @@ EXPORT_SYMBOL_GPL(clk_disable_regmap);/** * devm_clk_register_regmap - register a clk_regmap clock * +* @dev: reference to the caller's device * @rclk: clk to operate on * * Clocks that use regmap for their register I/O should register their
Signature · 1 line
2.25.1
Re: [PATCH 04/21] clk: qcom: clk-regmap: Provide missing description for 'devm_clk_register_regmap()'s dev param
Quoted 10 lines · Lee Jones
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 <[email protected]>Cc Bjorn Andersson <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>
Quoted 20 lines
Signed-off-by Lee Jones <[email protected]>--- drivers/clk/qcom/clk-regmap.c | 1 + 1 file changed, 1 insertion(+)drivers/clk/qcom/clk-regmap.c +1
-0@@ -87,6 +87,7 @@ EXPORT_SYMBOL_GPL(clk_disable_regmap);/** * devm_clk_register_regmap - register a clk_regmap clock * +* @dev: reference to the caller's device * @rclk: clk to operate on * * Clocks that use regmap for their register I/O should register their Signature · 1 line
2.25.1
Re: [PATCH 04/21] clk: qcom: clk-regmap: Provide missing description for 'devm_clk_register_regmap()'s dev param
In reply to Lee JonesQuoting Lee Jones (2021-01-26 04:45:23)
Quoted 4 lines
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'
Quoted 8 lines
Cc Andy Gross <[email protected]>Cc Bjorn Andersson <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Signed-off-by Lee Jones <[email protected]>---
Applied to clk-next
PATCH 5/21 clk: sunxi: clk-sun9i-core: Demote non-conformant kernel-doc headers
In reply to Lee JonesHeaders must describe their parameters.
Fixes the following W=1 kernel build warning(s):
drivers/clk/sunxi/clk-sun9i-core.c:27: warning: Function parameter or member 'req' not described in 'sun9i_a80_get_pll4_factors' drivers/clk/sunxi/clk-sun9i-core.c:100: warning: Function parameter or member 'req' not described in 'sun9i_a80_get_gt_factors' drivers/clk/sunxi/clk-sun9i-core.c:155: warning: Function parameter or member 'req' not described in 'sun9i_a80_get_ahb_factors' drivers/clk/sunxi/clk-sun9i-core.c:235: warning: Function parameter or member 'req' not described in 'sun9i_a80_get_apb1_factors'
--- drivers/clk/sunxi/clk-sun9i-core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/clk/sunxi/clk-sun9i-core.c +4 -4
@@ -14,7 +14,7 @@#include "clk-factors.h" -/** +/* * sun9i_a80_get_pll4_factors() - calculates n, p, m factors for PLL4 * PLL4 rate is calculated as follows * rate = (parent_rate * n >> p) / (m + 1);
@@ -90,7 +90,7 @@ static void __init sun9i_a80_pll4_setup(struct device_node *node)CLK_OF_DECLARE (sun9i_a80_pll4,"allwinner,sun9i-a80-pll4-clk" , sun9i_a80_pll4_setup); -/** +/* * sun9i_a80_get_gt_factors() - calculates m factor for GT * GT rate is calculated as follows * rate = parent_rate / (m + 1);
@@ -145,7 +145,7 @@ static void __init sun9i_a80_gt_setup(struct device_node *node)CLK_OF_DECLARE (sun9i_a80_gt,"allwinner,sun9i-a80-gt-clk" , sun9i_a80_gt_setup); -/** +/* * sun9i_a80_get_ahb_factors() - calculates p factor for AHB0/1/2 * AHB rate is calculated as follows * rate = parent_rate >> p;
@@ -225,7 +225,7 @@ static void __init sun9i_a80_apb0_setup(struct device_node *node)CLK_OF_DECLARE (sun9i_a80_apb0,"allwinner,sun9i-a80-apb0-clk" , sun9i_a80_apb0_setup); -/** +/* * sun9i_a80_get_apb1_factors() - calculates m, p factors for APB1 * APB1 rate is calculated as follows * rate = (parent_rate >> p) / (m + 1);
Signature · 7 lines
2.25.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 6/21 clk: sunxi: clk-usb: Demote obvious kernel-doc abuse
In reply to Lee JonesFixes the following W=1 kernel build warning(s):
drivers/clk/sunxi/clk-usb.c:22: warning: cannot understand function prototype: 'struct usb_reset_data '
--- drivers/clk/sunxi/clk-usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/sunxi/clk-usb.c +1 -1
@@ -15,7 +15,7 @@#include <linux/spinlock.h> -/** +/* * sunxi_usb_reset... - reset bits in usb clk registers handling */
Signature · 7 lines
2.25.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 7/21 clk: tegra: clk-tegra30: Remove unused variable 'reg'
In reply to Lee JonesFixes 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]
--- drivers/clk/tegra/clk-tegra30.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/clk/tegra/clk-tegra30.c +1 -4
@@ -1104,12 +1104,9 @@ static void tegra30_cpu_out_of_reset(u32 cpu)static void tegra30_enable_cpu_clock (u32 cpu) { -unsigned int reg; -writel (CPU_CLOCK (cpu), clk_base +TEGRA30_CLK_RST_CONTROLLER_CLK_CPU_CMPLX_CLR ); - reg =readl (clk_base + -TEGRA30_CLK_RST_CONTROLLER_CLK_CPU_CMPLX_CLR ); +readl (clk_base +TEGRA30_CLK_RST_CONTROLLER_CLK_CPU_CMPLX_CLR ); }static void tegra30_disable_cpu_clock (u32 cpu)
Signature · 1 line
2.25.1
Re: [PATCH 07/21] clk: tegra: clk-tegra30: Remove unused variable 'reg'
Quoting Lee Jones (2021-01-26 04:45:26)
Quoted 14 lines
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 <[email protected]>Cc Prashant Gaikwad <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc Thierry Reding <[email protected]>Cc Jonathan Hunter <[email protected]>Signed-off-by Lee Jones <[email protected]>
Quoted 1 line
---
Applied to clk-next
PATCH 8/21 clk: clkdev: Ignore suggestion to use gnu_printf() as it's not appropriate here
In reply to Lee JonesFixes 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]
--- drivers/clk/clkdev.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/clk/clkdev.c +7 -0
@@ -153,6 +153,11 @@ struct clk_lookup_alloc {char con_id[MAX_CON_ID ]; }; +#pragma GCC diagnostic push +#ifndef __clang__ +#pragma GCC diagnostic ignored "-Wsuggest-attribute=format" +#endif +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 &cla->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)
Signature · 7 lines
2.25.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Stephen Boyd
maintainerRe: [PATCH 08/21] clk: clkdev: Ignore suggestion to use gnu_printf() as it's not appropriate here
Quoting Lee Jones (2021-01-26 04:45:27)
Quoted 17 lines
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]--- drivers/clk/clkdev.c | 7 +++++++ 1 file changed, 7 insertions(+)drivers/clk/clkdev.c +0
-0
drivers/clk/clkdev.c struct clk_lookup_alloc { · line 159
Quoted 7 lines
drivers/clk/clkdev.c +4
-0@@ -153,6 +153,11 @@ struct clk_lookup_alloc {char con_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?
Quoted 16 lines
drivers/clk/clkdev.c +3
-0+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 &cla->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)Signature · 1 line
2.25.1
Re: [PATCH 08/21] clk: clkdev: Ignore suggestion to use gnu_printf() as it's not appropriate here
Quoted 21 lines · Stephen Boyd
Quoting Lee Jones (2021-01-26 04:45:27)
Quoted 20 lines
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]--- drivers/clk/clkdev.c | 7 +++++++ 1 file changed, 7 insertions(+)drivers/clk/clkdev.c +0
-0@@ -153,6 +153,11 @@ struct clk_lookup_alloc {char con_id[MAX_CON_ID ]; };
Quoted 6 lines
drivers/clk/clkdev.c struct clk_lookup_alloc { · line 159
Quoted 4 lines
drivers/clk/clkdev.c +4
-0+#pragma GCC diagnostic push +#ifndef __clang__ +#pragma GCC diagnostic ignored "-Wsuggest-attribute=format" +#endif Can this be some macro banished to
compiler.h?
This is probably a question for Arnd.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 08/21] clk: clkdev: Ignore suggestion to use gnu_printf() as it's not appropriate here
Quoted 23 lines · Lee Jones
Quoted 21 lines · Stephen Boyd
Quoting Lee Jones (2021-01-26 04:45:27)
Quoted 20 lines
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]--- drivers/clk/clkdev.c | 7 +++++++ 1 file changed, 7 insertions(+)drivers/clk/clkdev.c +0
-0@@ -153,6 +153,11 @@ struct clk_lookup_alloc {char con_id[MAX_CON_ID ]; };
Quoted 8 lines
Quoted 6 lines
drivers/clk/clkdev.c struct clk_lookup_alloc { · line 159
Quoted 4 lines
drivers/clk/clkdev.c +4
-0+#pragma GCC diagnostic push +#ifndef __clang__ +#pragma GCC diagnostic ignored "-Wsuggest-attribute=format" +#endif Can this be some macro banished to
compiler.h?This is probably a question for Arnd.
UPDATE: Arnd and I are working on a solution for this.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 9/21 clk: tegra: cvb: Provide missing description for 'tegra_cvb_add_opp_table()'s align param
In reply to Lee JonesFixes 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'
--- drivers/clk/tegra/cvb.c | 1 + 1 file changed, 1 insertion(+)
drivers/clk/tegra/cvb.c +1 -0
@@ -86,6 +86,7 @@ static int build_opp_table(struct device *dev, const struct cvb_table *table,* @dev: the struct device * for which the OPP table is built * @tables: array of CVB tables * @count: size of the previously mentioned array +* @align: parameters of the regulator step and offset * @process_id: process id of the HW module * @speedo_id: speedo id of the HW module * @speedo_value: speedo value of the HW module
Signature · 1 line
2.25.1
Re: [PATCH 09/21] clk: tegra: cvb: Provide missing description for 'tegra_cvb_add_opp_table()'s align param
Quoting Lee Jones (2021-01-26 04:45:28)
Quoted 13 lines
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 <[email protected]>Cc Prashant Gaikwad <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc Thierry Reding <[email protected]>Cc Jonathan Hunter <[email protected]>Signed-off-by Lee Jones <[email protected]>
Quoted 1 line
---
Applied to clk-next
PATCH 10/21 clk: ti: dpll44xx: Fix some potential doc-rot
In reply to Lee JonesFixes 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'
--- drivers/clk/ti/dpll44xx.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/clk/ti/dpll44xx.c +4 -2
@@ -102,7 +102,8 @@ static void omap4_dpll_lpmode_recalc(struct dpll_data *dd)/** * omap4_dpll_regm4xen_recalc - compute DPLL rate, considering REGM4XEN bit -* @clk: struct clk * of the DPLL to compute the rate for +* @hw: pointer to the clock to compute the rate for +* @parent_rate: clock rate of the DPLL parent * * Compute the output rate for the OMAP4 DPLL represented by @clk. * Takes the REGM4XEN bit into consideration, which is needed for the
@@ -134,8 +135,9 @@ unsigned long omap4_dpll_regm4xen_recalc(struct clk_hw *hw,/** * omap4_dpll_regm4xen_round_rate - round DPLL rate, considering REGM4XEN bit -* @clk: struct clk * of the DPLL to round a rate for +* @hw: struct hw_clk containing the struct clk * of the DPLL to round a rate for * @target_rate: the desired rate of the DPLL +* @parent_rate: clock rate of the DPLL parent * * Compute the rate that would be programmed into the DPLL hardware * for @clk if set_rate() were to be provided with the rate
Signature · 1 line
2.25.1
Re: [PATCH 10/21] clk: ti: dpll44xx: Fix some potential doc-rot
Quoting Lee Jones (2021-01-26 04:45:29)
Quoted 9 lines
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'
Quoted 7 lines
Cc Tero Kristo <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Signed-off-by Lee Jones <[email protected]>---
Applied to clk-next
PATCH 11/21 clk: renesas: renesas-cpg-mssr: Fix formatting issues for 'smstpcr_saved's documentation
In reply to Lee JonesFixes the following W=1 kernel build warning(s):
drivers/clk/renesas/renesas-cpg-mssr.c:168: warning: Function parameter or member 'smstpcr_saved' not described in 'cpg_mssr_priv'
--- drivers/clk/renesas/renesas-cpg-mssr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/clk/renesas/renesas-cpg-mssr.c +2 -2
@@ -136,8 +136,8 @@ static const u16 srstclr_for_v3u[] = {* @control_regs: Pointer to control registers array * @reset_regs: Pointer to reset registers array * @reset_clear_regs: Pointer to reset clearing registers array -* @smstpcr_saved[].mask: Mask of SMSTPCR[] bits under our control -* @smstpcr_saved[].val: Saved values of SMSTPCR[] +* @smstpcr_saved: [].mask: Mask of SMSTPCR[] bits under our control +* [].val: Saved values of SMSTPCR[] * @clks: Array containing all Core and Module Clocks */ struct cpg_mssr_priv {
Signature · 1 line
2.25.1
Re: [PATCH 11/21] clk: renesas: renesas-cpg-mssr: Fix formatting issues for 'smstpcr_saved's documentation
Quoted 11 lines · Lee Jones
Fixes the following W=1 kernel build warning(s):
drivers/clk/renesas/renesas-cpg-mssr.c:168: warning: Function parameter or member 'smstpcr_saved' not described in 'cpg_mssr_priv'Cc Geert Uytterhoeven <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc Philipp Zabel <[email protected]>Signed-off-by Lee Jones <[email protected]>
i.e. will queue in renesas-clk-for-v5.12.
Gr{oetje,eeting}s,
Geert
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
PATCH 12/21 clk: sunxi: clk-sun6i-ar100: Demote non-conformant kernel-doc header
In reply to Lee JonesFixes the following W=1 kernel build warning(s):
drivers/clk/sunxi/clk-sun6i-ar100.c:26: warning: Function parameter or member 'req' not described in 'sun6i_get_ar100_factors'
--- drivers/clk/sunxi/clk-sun6i-ar100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/sunxi/clk-sun6i-ar100.c +1 -1
@@ -16,7 +16,7 @@#include "clk-factors.h" -/** +/* * sun6i_get_ar100_factors - Calculates factors p, m for AR100 * * AR100 rate is calculated as follows
Signature · 7 lines
2.25.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 12/21] clk: sunxi: clk-sun6i-ar100: Demote non-conformant kernel-doc header
Quoted 23 lines · Lee Jones
Fixes the following W=1 kernel build warning(s):
drivers/clk/sunxi/clk-sun6i-ar100.c:26: warning: Function parameter or member 'req' not described in 'sun6i_get_ar100_factors'Cc "Emilio López" <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc Maxime Ripard <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Jernej Skrabec <[email protected]>Cc Boris BREZILLON <[email protected]>Signed-off-by Lee Jones <[email protected]>--- drivers/clk/sunxi/clk-sun6i-ar100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/clk/sunxi/clk-sun6i-ar100.c +0
-0
drivers/clk/sunxi/clk-sun6i-ar100.c line 22
Quoted 8 lines
drivers/clk/sunxi/clk-sun6i-ar100.c +1
-1@@ -16,7 +16,7 @@#include "clk-factors.h" -/** +/* * sun6i_get_ar100_factors - Calculates factors p, m for AR100 * * AR100 rate is calculated as follows
This is the sixth patch doing the exact same thing over the files in that folder you sent. Please fix all the occurences at once
Maxime
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 12/21] clk: sunxi: clk-sun6i-ar100: Demote non-conformant kernel-doc header
Quoted 27 lines · Maxime Ripard
Quoted 26 lines · Lee Jones
Fixes the following W=1 kernel build warning(s):
drivers/clk/sunxi/clk-sun6i-ar100.c:26: warning: Function parameter or member 'req' not described in 'sun6i_get_ar100_factors'Cc "Emilio López" <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc Maxime Ripard <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Jernej Skrabec <[email protected]>Cc Boris BREZILLON <[email protected]>Signed-off-by Lee Jones <[email protected]>--- drivers/clk/sunxi/clk-sun6i-ar100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/clk/sunxi/clk-sun6i-ar100.c +0
-0@@ -16,7 +16,7 @@#include "clk-factors.h"
Quoted 8 lines
drivers/clk/sunxi/clk-sun6i-ar100.c line 22
Quoted 5 lines
drivers/clk/sunxi/clk-sun6i-ar100.c +1
-1-/** +/* * sun6i_get_ar100_factors - Calculates factors p, m for AR100 * * AR100 rate is calculated as follows This is the sixth patch doing the exact same thing over the files in that folder you sent. Please fix all the occurences at once
No. That would make the whole clean-up process 10x harder than it already is
Before starting this endeavour there were 18,000+ warnings spread over 100's of files and 10's of subsystems that needed addressing (only a couple thousand left now thankfully). Some issues vastly different, some duplicated (much too much copy/pasting going which made things very frustrating at times).
Anyway, in order to work though them all gracefully and in a sensible time-frame I had to come up with a workable plan. Each subsystem is compiled separately and a script attempts to take out duplicate warnings and takes me through the build-log one file at a time. Once all of the warnings are fixed in a source-file, it moves on to the next file. The method is clean and allows me to handle this gargantuan task in bite-sized chunks.
Going though and pairing up similar changes is unsustainable for a task like this. It would add a lot of additional overhead and would slow down the rate of acceptance since source files tend to have different reviewers/maintainers - some working faster to review patches than others, leading to excessive lag times waiting for that one reviewer who takes weeks to review. Having each file addressed in a separate patch also helps revertability and bisectability. Not such a big problem with the documentation patches, but still.
Admittedly doing it this way *can* look a bit odd in *some* patch-sets when they hit the MLs - particularly clock it seems, where there hasn't even been a vague attempt to document any of the parameters in the kernel-doc headers - however the alternative would mean nothing would get done!
Signature · 9 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 12/21] clk: sunxi: clk-sun6i-ar100: Demote non-conformant kernel-doc header
Quoted 47 lines · Lee Jones
Quoted 27 lines · Maxime Ripard
Quoted 26 lines · Lee Jones
Fixes the following W=1 kernel build warning(s):
drivers/clk/sunxi/clk-sun6i-ar100.c:26: warning: Function parameter or member 'req' not described in 'sun6i_get_ar100_factors'Cc "Emilio López" <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc Maxime Ripard <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Jernej Skrabec <[email protected]>Cc Boris BREZILLON <[email protected]>Signed-off-by Lee Jones <[email protected]>--- drivers/clk/sunxi/clk-sun6i-ar100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/clk/sunxi/clk-sun6i-ar100.c +0
-0@@ -16,7 +16,7 @@#include "clk-factors.h" Quoted 8 lines
drivers/clk/sunxi/clk-sun6i-ar100.c line 22
Quoted 5 lines
drivers/clk/sunxi/clk-sun6i-ar100.c +1
-1-/** +/* * sun6i_get_ar100_factors - Calculates factors p, m for AR100 * * AR100 rate is calculated as follows This is the sixth patch doing the exact same thing over the files in that folder you sent. Please fix all the occurences at once
No. That would make the whole clean-up process 10x harder than it already is
Before starting this endeavour there were 18,000+ warnings spread over 100's of files and 10's of subsystems that needed addressing (only a couple thousand left now thankfully). Some issues vastly different, some duplicated (much too much copy/pasting going which made things very frustrating at times).
Quoted 7 lines
Anyway, in order to work though them all gracefully and in a sensible time-frame I had to come up with a workable plan. Each subsystem is compiled separately and a script attempts to take out duplicate warnings and takes me through the build-log one file at a time. Once all of the warnings are fixed in a source-file, it moves on to the next file. The method is clean and allows me to handle this gargantuan task in bite-sized chunks.
I mean, you have literally used the same commit log and the same changes over six different files in the same directory. Sure changes across different parts of the kernel can be painful, but it's really not what we're discussing here.
Quoted 6 lines
Going though and pairing up similar changes is unsustainable for a task like this. It would add a lot of additional overhead and would slow down the rate of acceptance since source files tend to have different reviewers/maintainers - some working faster to review patches than others, leading to excessive lag times waiting for that one reviewer who takes weeks to review.
Are you arguing that sending the same patch 6 times is easier and faster to review for the maintainer than the same changes in a single patch?
Quoted 3 lines
Having each file addressed in a separate patch also helps revertability and bisectability. Not such a big problem with the documentation patches, but still.
There's nothing to revert or bisect, those changes aren't functional changes.
Quoted 5 lines
Admittedly doing it this way *can* look a bit odd in *some* patch-sets when they hit the MLs - particularly clock it seems, where there hasn't even been a vague attempt to document any of the parameters in the kernel-doc headers - however the alternative would mean nothing would get done!
Yeah, and even though properly documenting the functions would have been the right way to fix those warnings, I didn't ask you to do that since I was expecting it to be daunting. Surely we can meet half-way
Maxime
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 12/21] clk: sunxi: clk-sun6i-ar100: Demote non-conformant kernel-doc header
Quoted 56 lines · Maxime Ripard
Quoted 47 lines · Lee Jones
Quoted 27 lines · Maxime Ripard
Quoted 26 lines · Lee Jones
Fixes the following W=1 kernel build warning(s):
drivers/clk/sunxi/clk-sun6i-ar100.c:26: warning: Function parameter or member 'req' not described in 'sun6i_get_ar100_factors'Cc "Emilio López" <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc Maxime Ripard <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Jernej Skrabec <[email protected]>Cc Boris BREZILLON <[email protected]>Signed-off-by Lee Jones <[email protected]>--- drivers/clk/sunxi/clk-sun6i-ar100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/clk/sunxi/clk-sun6i-ar100.c +0
-0@@ -16,7 +16,7 @@#include "clk-factors.h" Quoted 8 lines
drivers/clk/sunxi/clk-sun6i-ar100.c line 22
Quoted 5 lines
drivers/clk/sunxi/clk-sun6i-ar100.c +1
-1-/** +/* * sun6i_get_ar100_factors - Calculates factors p, m for AR100 * * AR100 rate is calculated as follows This is the sixth patch doing the exact same thing over the files in that folder you sent. Please fix all the occurences at once
No. That would make the whole clean-up process 10x harder than it already is
Before starting this endeavour there were 18,000+ warnings spread over 100's of files and 10's of subsystems that needed addressing (only a couple thousand left now thankfully). Some issues vastly different, some duplicated (much too much copy/pasting going which made things very frustrating at times).
Quoted 7 lines
Anyway, in order to work though them all gracefully and in a sensible time-frame I had to come up with a workable plan. Each subsystem is compiled separately and a script attempts to take out duplicate warnings and takes me through the build-log one file at a time. Once all of the warnings are fixed in a source-file, it moves on to the next file. The method is clean and allows me to handle this gargantuan task in bite-sized chunks.
Quoted 2 lines
I mean, you have literally used the same commit log and the same changes over six different files in the same directory.
Yes, that happens. It's an unfortunate side-effect of the same ol' issues repeating themselves over and over. Mostly due to copy/paste of mundane code segments such as function documentation.
Quoted 3 lines
Sure changes across
different parts of the kernel can be painful, but it's really not what we're discussing here.
It would have even been painful to post-process patches within the same subsystem. For instance, I've just finished cleaning up GPU which was a mammoth task where most of the issues were perpetually duplicated.
I will admit though, that here in Clock, it would be somewhat easier.
Quoted 9 lines
Quoted 6 lines
Going though and pairing up similar changes is unsustainable for a task like this. It would add a lot of additional overhead and would slow down the rate of acceptance since source files tend to have different reviewers/maintainers - some working faster to review patches than others, leading to excessive lag times waiting for that one reviewer who takes weeks to review.
Are you arguing that sending the same patch 6 times is easier and faster to review for the maintainer than the same changes in a single patch?
The issue I see with the Clock, is that some files are maintained by individual driver Maintainers and others by subsystem Maintainers. So the post-process here is that much more painful (as it can't be easily scripted using get_maintainer.pl) and the aforementioned lag-time issues come into play while we wait for sleepy reviewers.
Quoted 6 lines
Quoted 3 lines
Having each file addressed in a separate patch also helps revertability and bisectability. Not such a big problem with the documentation patches, but still.
There's nothing to revert or bisect, those changes aren't functional changes.
Right, I did mention that.
Quoted 9 lines
Quoted 5 lines
Admittedly doing it this way *can* look a bit odd in *some* patch-sets when they hit the MLs - particularly clock it seems, where there hasn't even been a vague attempt to document any of the parameters in the kernel-doc headers - however the alternative would mean nothing would get done!
Yeah, and even though properly documenting the functions would have been the right way to fix those warnings, I didn't ask you to do that since I was expecting it to be daunting.
There are a couple of schools of thought on function documentation. The conflicting one to yours is that Kernel-doc headers should only be used if they are part of an API and have an accompanying kernel-doc::
tag in Documentation. The functions touched here do not.
NB: Fortunately the functions we're discussing are all static or else scripts/find-unused-docs.sh would complain about them also.
Personally, I am in the middle. If authors have had a good go at documenting functions and their parameters, I'll make the effort to fix any doc-rot or oversights. However if, like here, no such effort has been made, they get demoted. Nothing stopping authors fixing them up properly and re-promoting them again though. Essentially I'm trying to avoid a situation where authors throw something together half-heatedly, safe in the knowledge that someone will come fix and beautify things for them.
Quoted 1 line
Surely we can meet half-way
I'm always happy to collaborate. What does half-way look like?
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 13/21 clk: qcom: gcc-ipq4019: Remove unused variable 'ret'
In reply to Lee JonesFixes 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]
--- drivers/clk/qcom/gcc-ipq4019.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
drivers/clk/qcom/gcc-ipq4019.c +3 -4
@@ -1276,16 +1276,15 @@ static int clk_cpu_div_set_rate(struct clk_hw *hw, unsigned long rate,struct clk_fepll *pll =to_clk_fepll (hw);const struct freq_tbl *f;u32 mask; -int ret; f =qcom_find_freq (pll->freq_tbl, rate);if (!f)return -EINVAL ; mask = (BIT (pll->cdiv.width) -1 ) << pll->cdiv.shift; - ret =regmap_update_bits (pll->cdiv.clkr.regmap, - pll->cdiv.reg, mask, - f->pre_div << pll->cdiv.shift); +regmap_update_bits (pll->cdiv.clkr.regmap, + pll->cdiv.reg, mask, + f->pre_div << pll->cdiv.shift);/* * There is no status bit which can be checked for successful CPU * divider update operation so using delay for the same.
Signature · 1 line
2.25.1
Re: [PATCH 13/21] clk: qcom: gcc-ipq4019: Remove unused variable 'ret'
Quoted 11 lines · Lee Jones
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 <[email protected]>Cc Bjorn Andersson <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>
Quoted 32 lines
Signed-off-by Lee Jones <[email protected]>--- drivers/clk/qcom/gcc-ipq4019.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)drivers/clk/qcom/gcc-ipq4019.c +3
-4@@ -1276,16 +1276,15 @@ static int clk_cpu_div_set_rate(struct clk_hw *hw, unsigned long rate,struct clk_fepll *pll =to_clk_fepll (hw);const struct freq_tbl *f;u32 mask; -int ret; f =qcom_find_freq (pll->freq_tbl, rate);if (!f)return -EINVAL ; mask = (BIT (pll->cdiv.width) -1 ) << pll->cdiv.shift; - ret =regmap_update_bits (pll->cdiv.clkr.regmap, - pll->cdiv.reg, mask, - f->pre_div << pll->cdiv.shift); +regmap_update_bits (pll->cdiv.clkr.regmap, + pll->cdiv.reg, mask, + f->pre_div << pll->cdiv.shift);/* * There is no status bit which can be checked for successful CPU * divider update operation so using delay for the same. Signature · 1 line
2.25.1
Re: [PATCH 13/21] clk: qcom: gcc-ipq4019: Remove unused variable 'ret'
In reply to Lee JonesQuoting Lee Jones (2021-01-26 04:45:32)
Quoted 5 lines
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]
Quoted 8 lines
Cc Andy Gross <[email protected]>Cc Bjorn Andersson <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Signed-off-by Lee Jones <[email protected]>---
Applied to clk-next
PATCH 14/21 clk: clk-fixed-mmio: Demote obvious kernel-doc abuse
In reply to Lee JonesFixes 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'
--- drivers/clk/clk-fixed-mmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/clk-fixed-mmio.c +1 -1
@@ -55,7 +55,7 @@ static void __init of_fixed_mmio_clk_setup(struct device_node *node) }CLK_OF_DECLARE (fixed_mmio_clk,"fixed-mmio-clock" , of_fixed_mmio_clk_setup); -/** +/* * This is not executed when of_fixed_mmio_clk_setup succeeded. */ static int of_fixed_mmio_clk_probe (struct platform_device *pdev)
Signature · 1 line
2.25.1
Re: [PATCH 14/21] clk: clk-fixed-mmio: Demote obvious kernel-doc abuse
Quoting Lee Jones (2021-01-26 04:45:33)
Quoted 10 lines
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 <[email protected]>Cc Stephen Boyd <[email protected]>Cc Jan Kotas <[email protected]>Signed-off-by Lee Jones <[email protected]>---
Applied to clk-next
PATCH 15/21 clk: clk-npcm7xx: Remove unused static const tables 'npcm7xx_gates' and 'npcm7xx_divs_fx'
In reply to Lee JonesFixes 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=]
--- drivers/clk/clk-npcm7xx.c | 108 -------------------------------------- 1 file changed, 108 deletions(-)
drivers/clk/clk-npcm7xx.c +0 -108
@@ -361,13 +361,6 @@ static const struct npcm7xx_clk_mux_data npcm7xx_muxes[] __initconst = { dvcssel_mux_parents, ARRAY_SIZE(dvcssel_mux_parents), 0, -1}, }; -/* fixed ratio dividers (no register): */ -static const struct npcm7xx_clk_div_fixed_data npcm7xx_divs_fx[]__initconst = { - {1 ,2 ,NPCM7XX_CLK_S_MC ,NPCM7XX_CLK_S_MC_MUX ,0 ,NPCM7XX_CLK_MC }, - {1 ,2 ,NPCM7XX_CLK_S_PLL1_DIV2 ,NPCM7XX_CLK_S_PLL1 ,0 ,-1 }, - {1 ,2 ,NPCM7XX_CLK_S_PLL2_DIV2 ,NPCM7XX_CLK_S_PLL2 ,0 ,-1 }, -}; -/* configurable dividers: */ static const struct npcm7xx_clk_div_data npcm7xx_divs[]__initconst = { {NPCM7XX_CLKDIV1 ,28 ,3 ,NPCM7XX_CLK_S_ADC ,
@@ -435,107 +428,6 @@ static const struct npcm7xx_clk_div_data npcm7xx_divs[] __initconst = { }; -static const struct npcm7xx_clk_gate_data npcm7xx_gates[]__initconst = { - {NPCM7XX_CLKEN1 ,31 ,"smb1-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,30 ,"smb0-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,29 ,"smb7-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,28 ,"smb6-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,27 ,"adc-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,26 ,"wdt-gate" ,NPCM7XX_CLK_S_TIMER ,0 }, - {NPCM7XX_CLKEN1 ,25 ,"usbdev3-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,24 ,"usbdev6-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,23 ,"usbdev5-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,22 ,"usbdev4-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,21 ,"emc2-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,20 ,"timer5_9-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,19 ,"timer0_4-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,18 ,"pwmm0-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, - {NPCM7XX_CLKEN1 ,17 ,"huart-gate" ,NPCM7XX_CLK_S_UART ,0 }, - {NPCM7XX_CLKEN1 ,16 ,"smb5-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,15 ,"smb4-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,14 ,"smb3-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,13 ,"smb2-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,12 ,"mc-gate" ,NPCM7XX_CLK_S_MC ,0 }, - {NPCM7XX_CLKEN1 ,11 ,"uart01-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,10 ,"aes-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,9 ,"peci-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, - {NPCM7XX_CLKEN1 ,8 ,"usbdev2-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,7 ,"uart23-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,6 ,"emc1-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,5 ,"usbdev1-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,4 ,"shm-gate" ,NPCM7XX_CLK_S_AHB ,0 }, -/* bit 3 is reserved */ - {NPCM7XX_CLKEN1 ,2 ,"kcs-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,1 ,"spi3-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,0 ,"spi0-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - - {NPCM7XX_CLKEN2 ,31 ,"cp-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,30 ,"tock-gate" ,NPCM7XX_CLK_S_TOCK ,0 }, -/* bit 29 is reserved */ - {NPCM7XX_CLKEN2 ,28 ,"gmac1-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,27 ,"usbif-gate" ,NPCM7XX_CLK_S_USBIF ,0 }, - {NPCM7XX_CLKEN2 ,26 ,"usbhost-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,25 ,"gmac2-gate" ,NPCM7XX_CLK_S_AHB ,0 }, -/* bit 24 is reserved */ - {NPCM7XX_CLKEN2 ,23 ,"pspi2-gate" ,NPCM7XX_CLK_S_APB5 ,0 }, - {NPCM7XX_CLKEN2 ,22 ,"pspi1-gate" ,NPCM7XX_CLK_S_APB5 ,0 }, - {NPCM7XX_CLKEN2 ,21 ,"3des-gate" ,NPCM7XX_CLK_S_AHB ,0 }, -/* bit 20 is reserved */ - {NPCM7XX_CLKEN2 ,19 ,"siox2-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, - {NPCM7XX_CLKEN2 ,18 ,"siox1-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, -/* bit 17 is reserved */ - {NPCM7XX_CLKEN2 ,16 ,"fuse-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, -/* bit 15 is reserved */ - {NPCM7XX_CLKEN2 ,14 ,"vcd-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,13 ,"ece-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,12 ,"vdma-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,11 ,"ahbpcibrg-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,10 ,"gfxsys-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN2 ,9 ,"sdhc-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,8 ,"mmc-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,7 ,"mft7-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,6 ,"mft6-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,5 ,"mft5-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,4 ,"mft4-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,3 ,"mft3-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,2 ,"mft2-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,1 ,"mft1-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,0 ,"mft0-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - - {NPCM7XX_CLKEN3 ,31 ,"gpiom7-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,30 ,"gpiom6-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,29 ,"gpiom5-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,28 ,"gpiom4-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,27 ,"gpiom3-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,26 ,"gpiom2-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,25 ,"gpiom1-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,24 ,"gpiom0-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,23 ,"espi-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,22 ,"smb11-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,21 ,"smb10-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,20 ,"smb9-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,19 ,"smb8-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,18 ,"smb15-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,17 ,"rng-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,16 ,"timer10_14-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,15 ,"pcirc-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,14 ,"sececc-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,13 ,"sha-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,12 ,"smb14-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, -/* bit 11 is reserved */ -/* bit 10 is reserved */ - {NPCM7XX_CLKEN3 ,9 ,"pcimbx-gate" ,NPCM7XX_CLK_S_AHB ,0 }, -/* bit 8 is reserved */ - {NPCM7XX_CLKEN3 ,7 ,"usbdev9-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,6 ,"usbdev8-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,5 ,"usbdev7-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,4 ,"usbdev0-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,3 ,"smb13-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,2 ,"spix-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,1 ,"smb12-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,0 ,"pwmm1-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, -}; -static DEFINE_SPINLOCK (npcm7xx_clk_lock);static void __init npcm7xx_clk_init (struct device_node *clk_np)
Signature · 1 line
2.25.1
Re: [PATCH 15/21] clk: clk-npcm7xx: Remove unused static const tables 'npcm7xx_gates' and 'npcm7xx_divs_fx'
Thanks for the fix !
Quoted 156 lines · Lee Jones
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 <[email protected]>Cc Tomer Maimon <[email protected]>Cc Tali Perry <[email protected]>Cc Patrick Venture <[email protected]>Cc Nancy Yuen <[email protected]>Cc Benjamin Fair <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc Nuvoton Technologies <[email protected]>Signed-off-by Lee Jones <[email protected]>--- drivers/clk/clk-npcm7xx.c | 108 -------------------------------------- 1 file changed, 108 deletions(-)drivers/clk/clk-npcm7xx.c +0
-7@@ -361,13 +361,6 @@ static const struct npcm7xx_clk_mux_data npcm7xx_muxes[] __initconst = { dvcssel_mux_parents, ARRAY_SIZE(dvcssel_mux_parents), 0, -1}, }; -/* fixed ratio dividers (no register): */ -static const struct npcm7xx_clk_div_fixed_data npcm7xx_divs_fx[] __initconst = { - {1 ,2 ,NPCM7XX_CLK_S_MC ,NPCM7XX_CLK_S_MC_MUX ,0 ,NPCM7XX_CLK_MC }, - {1 ,2 ,NPCM7XX_CLK_S_PLL1_DIV2 ,NPCM7XX_CLK_S_PLL1 ,0 ,-1 }, - {1 ,2 ,NPCM7XX_CLK_S_PLL2_DIV2 ,NPCM7XX_CLK_S_PLL2 ,0 ,-1 }, -}; -/* configurable dividers: */ static const struct npcm7xx_clk_div_data npcm7xx_divs[] __initconst = { {NPCM7XX_CLKDIV1, 28, 3, NPCM7XX_CLK_S_ADC,drivers/clk/clk-npcm7xx.c +0
-101@@ -435,107 +428,6 @@ static const struct npcm7xx_clk_div_data npcm7xx_divs[] __initconst = { }; -static const struct npcm7xx_clk_gate_data npcm7xx_gates[]__initconst = { - {NPCM7XX_CLKEN1 ,31 ,"smb1-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,30 ,"smb0-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,29 ,"smb7-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,28 ,"smb6-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,27 ,"adc-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,26 ,"wdt-gate" ,NPCM7XX_CLK_S_TIMER ,0 }, - {NPCM7XX_CLKEN1 ,25 ,"usbdev3-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,24 ,"usbdev6-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,23 ,"usbdev5-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,22 ,"usbdev4-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,21 ,"emc2-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,20 ,"timer5_9-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,19 ,"timer0_4-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,18 ,"pwmm0-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, - {NPCM7XX_CLKEN1 ,17 ,"huart-gate" ,NPCM7XX_CLK_S_UART ,0 }, - {NPCM7XX_CLKEN1 ,16 ,"smb5-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,15 ,"smb4-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,14 ,"smb3-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,13 ,"smb2-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,12 ,"mc-gate" ,NPCM7XX_CLK_S_MC ,0 }, - {NPCM7XX_CLKEN1 ,11 ,"uart01-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,10 ,"aes-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,9 ,"peci-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, - {NPCM7XX_CLKEN1 ,8 ,"usbdev2-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,7 ,"uart23-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,6 ,"emc1-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,5 ,"usbdev1-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,4 ,"shm-gate" ,NPCM7XX_CLK_S_AHB ,0 }, -/* bit 3 is reserved */ - {NPCM7XX_CLKEN1 ,2 ,"kcs-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,1 ,"spi3-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,0 ,"spi0-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - - {NPCM7XX_CLKEN2 ,31 ,"cp-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,30 ,"tock-gate" ,NPCM7XX_CLK_S_TOCK ,0 }, -/* bit 29 is reserved */ - {NPCM7XX_CLKEN2 ,28 ,"gmac1-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,27 ,"usbif-gate" ,NPCM7XX_CLK_S_USBIF ,0 }, - {NPCM7XX_CLKEN2 ,26 ,"usbhost-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,25 ,"gmac2-gate" ,NPCM7XX_CLK_S_AHB ,0 }, -/* bit 24 is reserved */ - {NPCM7XX_CLKEN2 ,23 ,"pspi2-gate" ,NPCM7XX_CLK_S_APB5 ,0 }, - {NPCM7XX_CLKEN2 ,22 ,"pspi1-gate" ,NPCM7XX_CLK_S_APB5 ,0 }, - {NPCM7XX_CLKEN2 ,21 ,"3des-gate" ,NPCM7XX_CLK_S_AHB ,0 }, -/* bit 20 is reserved */ - {NPCM7XX_CLKEN2 ,19 ,"siox2-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, - {NPCM7XX_CLKEN2 ,18 ,"siox1-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, -/* bit 17 is reserved */ - {NPCM7XX_CLKEN2 ,16 ,"fuse-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, -/* bit 15 is reserved */ - {NPCM7XX_CLKEN2 ,14 ,"vcd-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,13 ,"ece-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,12 ,"vdma-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,11 ,"ahbpcibrg-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,10 ,"gfxsys-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN2 ,9 ,"sdhc-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,8 ,"mmc-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,7 ,"mft7-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,6 ,"mft6-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,5 ,"mft5-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,4 ,"mft4-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,3 ,"mft3-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,2 ,"mft2-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,1 ,"mft1-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,0 ,"mft0-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - - {NPCM7XX_CLKEN3 ,31 ,"gpiom7-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,30 ,"gpiom6-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,29 ,"gpiom5-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,28 ,"gpiom4-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,27 ,"gpiom3-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,26 ,"gpiom2-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,25 ,"gpiom1-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,24 ,"gpiom0-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,23 ,"espi-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,22 ,"smb11-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,21 ,"smb10-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,20 ,"smb9-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,19 ,"smb8-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,18 ,"smb15-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,17 ,"rng-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,16 ,"timer10_14-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,15 ,"pcirc-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,14 ,"sececc-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,13 ,"sha-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,12 ,"smb14-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, -/* bit 11 is reserved */ -/* bit 10 is reserved */ - {NPCM7XX_CLKEN3 ,9 ,"pcimbx-gate" ,NPCM7XX_CLK_S_AHB ,0 }, -/* bit 8 is reserved */ - {NPCM7XX_CLKEN3 ,7 ,"usbdev9-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,6 ,"usbdev8-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,5 ,"usbdev7-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,4 ,"usbdev0-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,3 ,"smb13-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,2 ,"spix-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,1 ,"smb12-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,0 ,"pwmm1-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, -}; -static DEFINE_SPINLOCK (npcm7xx_clk_lock);static void
__initnpcm7xx_clk_init(struct device_node *clk_np)
--
2.25.1
Tali Perry
maintainerRe: [PATCH 15/21] clk: clk-npcm7xx: Remove unused static const tables 'npcm7xx_gates' and 'npcm7xx_divs_fx'
resend
Quoted 157 lines · Tali Perry
Reviewed-by Tali Perry <[email protected]>Thanks for the fix !
Quoted 151 lines · Lee Jones
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 <[email protected]>Cc Tomer Maimon <[email protected]>Cc Tali Perry <[email protected]>Cc Patrick Venture <[email protected]>Cc Nancy Yuen <[email protected]>Cc Benjamin Fair <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc Nuvoton Technologies <[email protected]>Signed-off-by Lee Jones <[email protected]>--- drivers/clk/clk-npcm7xx.c | 108 -------------------------------------- 1 file changed, 108 deletions(-)drivers/clk/clk-npcm7xx.c +0
-109@@ -361,13 +361,6 @@ static const struct npcm7xx_clk_mux_data npcm7xx_muxes[] __initconst = { dvcssel_mux_parents, ARRAY_SIZE(dvcssel_mux_parents), 0, -1}, }; -/* fixed ratio dividers (no register): */ -static const struct npcm7xx_clk_div_fixed_data npcm7xx_divs_fx[]__initconst = { - {1 ,2 ,NPCM7XX_CLK_S_MC ,NPCM7XX_CLK_S_MC_MUX ,0 ,NPCM7XX_CLK_MC }, - {1 ,2 ,NPCM7XX_CLK_S_PLL1_DIV2 ,NPCM7XX_CLK_S_PLL1 ,0 ,-1 }, - {1 ,2 ,NPCM7XX_CLK_S_PLL2_DIV2 ,NPCM7XX_CLK_S_PLL2 ,0 ,-1 }, -}; -/* configurable dividers: */ static const struct npcm7xx_clk_div_data npcm7xx_divs[]__initconst = { {NPCM7XX_CLKDIV1 ,28 ,3 ,NPCM7XX_CLK_S_ADC ,@@ -435,107 +428,6 @@ static const struct npcm7xx_clk_div_data npcm7xx_divs[] __initconst = { }; -static const struct npcm7xx_clk_gate_data npcm7xx_gates[]__initconst = { - {NPCM7XX_CLKEN1 ,31 ,"smb1-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,30 ,"smb0-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,29 ,"smb7-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,28 ,"smb6-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,27 ,"adc-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,26 ,"wdt-gate" ,NPCM7XX_CLK_S_TIMER ,0 }, - {NPCM7XX_CLKEN1 ,25 ,"usbdev3-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,24 ,"usbdev6-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,23 ,"usbdev5-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,22 ,"usbdev4-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,21 ,"emc2-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,20 ,"timer5_9-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,19 ,"timer0_4-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,18 ,"pwmm0-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, - {NPCM7XX_CLKEN1 ,17 ,"huart-gate" ,NPCM7XX_CLK_S_UART ,0 }, - {NPCM7XX_CLKEN1 ,16 ,"smb5-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,15 ,"smb4-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,14 ,"smb3-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,13 ,"smb2-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN1 ,12 ,"mc-gate" ,NPCM7XX_CLK_S_MC ,0 }, - {NPCM7XX_CLKEN1 ,11 ,"uart01-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,10 ,"aes-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,9 ,"peci-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, - {NPCM7XX_CLKEN1 ,8 ,"usbdev2-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,7 ,"uart23-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,6 ,"emc1-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,5 ,"usbdev1-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,4 ,"shm-gate" ,NPCM7XX_CLK_S_AHB ,0 }, -/* bit 3 is reserved */ - {NPCM7XX_CLKEN1 ,2 ,"kcs-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN1 ,1 ,"spi3-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN1 ,0 ,"spi0-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - - {NPCM7XX_CLKEN2 ,31 ,"cp-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,30 ,"tock-gate" ,NPCM7XX_CLK_S_TOCK ,0 }, -/* bit 29 is reserved */ - {NPCM7XX_CLKEN2 ,28 ,"gmac1-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,27 ,"usbif-gate" ,NPCM7XX_CLK_S_USBIF ,0 }, - {NPCM7XX_CLKEN2 ,26 ,"usbhost-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,25 ,"gmac2-gate" ,NPCM7XX_CLK_S_AHB ,0 }, -/* bit 24 is reserved */ - {NPCM7XX_CLKEN2 ,23 ,"pspi2-gate" ,NPCM7XX_CLK_S_APB5 ,0 }, - {NPCM7XX_CLKEN2 ,22 ,"pspi1-gate" ,NPCM7XX_CLK_S_APB5 ,0 }, - {NPCM7XX_CLKEN2 ,21 ,"3des-gate" ,NPCM7XX_CLK_S_AHB ,0 }, -/* bit 20 is reserved */ - {NPCM7XX_CLKEN2 ,19 ,"siox2-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, - {NPCM7XX_CLKEN2 ,18 ,"siox1-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, -/* bit 17 is reserved */ - {NPCM7XX_CLKEN2 ,16 ,"fuse-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, -/* bit 15 is reserved */ - {NPCM7XX_CLKEN2 ,14 ,"vcd-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,13 ,"ece-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,12 ,"vdma-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,11 ,"ahbpcibrg-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,10 ,"gfxsys-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN2 ,9 ,"sdhc-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,8 ,"mmc-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN2 ,7 ,"mft7-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,6 ,"mft6-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,5 ,"mft5-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,4 ,"mft4-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,3 ,"mft3-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,2 ,"mft2-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,1 ,"mft1-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - {NPCM7XX_CLKEN2 ,0 ,"mft0-gate" ,NPCM7XX_CLK_S_APB4 ,0 }, - - {NPCM7XX_CLKEN3 ,31 ,"gpiom7-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,30 ,"gpiom6-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,29 ,"gpiom5-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,28 ,"gpiom4-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,27 ,"gpiom3-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,26 ,"gpiom2-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,25 ,"gpiom1-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,24 ,"gpiom0-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,23 ,"espi-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,22 ,"smb11-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,21 ,"smb10-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,20 ,"smb9-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,19 ,"smb8-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,18 ,"smb15-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,17 ,"rng-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,16 ,"timer10_14-gate" ,NPCM7XX_CLK_S_APB1 ,0 }, - {NPCM7XX_CLKEN3 ,15 ,"pcirc-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,14 ,"sececc-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,13 ,"sha-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,12 ,"smb14-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, -/* bit 11 is reserved */ -/* bit 10 is reserved */ - {NPCM7XX_CLKEN3 ,9 ,"pcimbx-gate" ,NPCM7XX_CLK_S_AHB ,0 }, -/* bit 8 is reserved */ - {NPCM7XX_CLKEN3 ,7 ,"usbdev9-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,6 ,"usbdev8-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,5 ,"usbdev7-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,4 ,"usbdev0-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,3 ,"smb13-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,2 ,"spix-gate" ,NPCM7XX_CLK_S_AHB ,0 }, - {NPCM7XX_CLKEN3 ,1 ,"smb12-gate" ,NPCM7XX_CLK_S_APB2 ,0 }, - {NPCM7XX_CLKEN3 ,0 ,"pwmm1-gate" ,NPCM7XX_CLK_S_APB3 ,0 }, -}; -static DEFINE_SPINLOCK (npcm7xx_clk_lock);static void __init npcm7xx_clk_init (struct device_node *clk_np) --2.25.1
Re: [PATCH 15/21] clk: clk-npcm7xx: Remove unused static const tables 'npcm7xx_gates' and 'npcm7xx_divs_fx'
In reply to Lee JonesQuoting Lee Jones (2021-01-26 04:45:34)
Quoted 17 lines
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 <[email protected]>Cc Tomer Maimon <[email protected]>Cc Tali Perry <[email protected]>Cc Patrick Venture <[email protected]>Cc Nancy Yuen <[email protected]>Cc Benjamin Fair <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc Nuvoton Technologies <[email protected]>Signed-off-by Lee Jones <[email protected]>
Quoted 1 line
---
Applied to clk-next
PATCH 16/21 clk: qcom: mmcc-msm8974: Remove unused static const tables 'mmcc_xo_mmpll0_1_2_gpll0{map}'
In reply to Lee JonesFixes 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=]
--- drivers/clk/qcom/mmcc-msm8974.c | 16 ---------------- 1 file changed, 16 deletions(-)
drivers/clk/qcom/mmcc-msm8974.c +0 -16
@@ -74,22 +74,6 @@ static const char * const mmcc_xo_mmpll0_dsi_hdmi_gpll0[] = { "dsi1pll", }; -static const struct parent_map mmcc_xo_mmpll0_1_2_gpll0_map[] = { - {P_XO ,0 }, - {P_MMPLL0 ,1 }, - {P_MMPLL1 ,2 }, - {P_GPLL0 ,5 }, - {P_MMPLL2 ,3 } -}; - -static const char *const mmcc_xo_mmpll0_1_2_gpll0[] = { -"xo" , -"mmpll0_vote" , -"mmpll1_vote" , -"mmss_gpll0_vote" , -"mmpll2" , -}; -static const struct parent_map mmcc_xo_mmpll0_1_3_gpll0_map[] = { {P_XO ,0 }, {P_MMPLL0 ,1 },
Signature · 1 line
2.25.1
Re: [PATCH 16/21] clk: qcom: mmcc-msm8974: Remove unused static const tables 'mmcc_xo_mmpll0_1_2_gpll0{map}'
Quoted 11 lines · Lee Jones
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 <[email protected]>Cc Bjorn Andersson <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>
Quoted 35 lines
Signed-off-by Lee Jones <[email protected]>--- drivers/clk/qcom/mmcc-msm8974.c | 16 ---------------- 1 file changed, 16 deletions(-)drivers/clk/qcom/mmcc-msm8974.c +0
-16@@ -74,22 +74,6 @@ static const char * const mmcc_xo_mmpll0_dsi_hdmi_gpll0[] = { "dsi1pll", }; -static const struct parent_map mmcc_xo_mmpll0_1_2_gpll0_map[] = { - {P_XO ,0 }, - {P_MMPLL0 ,1 }, - {P_MMPLL1 ,2 }, - {P_GPLL0 ,5 }, - {P_MMPLL2 ,3 } -}; - -static const char *const mmcc_xo_mmpll0_1_2_gpll0[] = { -"xo" , -"mmpll0_vote" , -"mmpll1_vote" , -"mmss_gpll0_vote" , -"mmpll2" , -}; -static const struct parent_map mmcc_xo_mmpll0_1_3_gpll0_map[] = { {P_XO ,0 }, {P_MMPLL0 ,1 },Signature · 1 line
2.25.1
Re: [PATCH 16/21] clk: qcom: mmcc-msm8974: Remove unused static const tables 'mmcc_xo_mmpll0_1_2_gpll0{map}'
In reply to Lee JonesQuoting Lee Jones (2021-01-26 04:45:35)
Quoted 5 lines
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=]
Quoted 8 lines
Cc Andy Gross <[email protected]>Cc Bjorn Andersson <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Signed-off-by Lee Jones <[email protected]>---
Applied to clk-next
PATCH 17/21 clk: clk-xgene: Add description for 'mask' and fix formatting for 'flags'
In reply to Lee JonesFixes 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'
--- drivers/clk/clk-xgene.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/clk/clk-xgene.c +2 -3
@@ -206,17 +206,16 @@ static void xgene_pcppllclk_init(struct device_node *np)* @hw: handle between common and hardware-specific interfaces * @reg: register containing the fractional scale multiplier (scaler) * @shift: shift to the unit bit field +* @mask: mask to the unit bit field * @denom: 1/denominator unit * @lock: register lock -* Flags: -* XGENE_CLK_PMD_SCALE_INVERTED - By default the scaler is the value read +* @flags: XGENE_CLK_PMD_SCALE_INVERTED - By default the scaler is the value read * from the register plus one. For example, * 0 for (0 + 1) / denom, * 1 for (1 + 1) / denom and etc. * If this flag is set, it is * 0 for (denom - 0) / denom, * 1 for (denom - 1) / denom and etc. -* */ struct xgene_clk_pmd {struct clk_hw hw;
Signature · 1 line
2.25.1
Re: [PATCH 17/21] clk: clk-xgene: Add description for 'mask' and fix formatting for 'flags'
Quoting Lee Jones (2021-01-26 04:45:36)
Quoted 11 lines
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 <[email protected]>Cc Stephen Boyd <[email protected]>Cc Loc Ho <[email protected]>Signed-off-by Lee Jones <[email protected]>---
Applied to clk-next
PATCH 18/21 clk: qcom: clk-rpm: Remove a bunch of superfluous code
In reply to Lee JonesFixes 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=]
--- drivers/clk/qcom/clk-rpm.c | 63 -------------------------------------- 1 file changed, 63 deletions(-)
drivers/clk/qcom/clk-rpm.c +0 -63
@@ -73,62 +73,6 @@ }, \ } -#define DEFINE_CLK_RPM_PXO_BRANCH (_platform, _name, _active, r_id, r) \ - static struct clk_rpm _platform##_##_active; \ - static struct clk_rpm _platform##_##_name = { \ - .rpm_clk_id = (r_id), \ - .active_only = true, \ - .peer = &_platform##_##_active, \ - .rate = (r), \ - .branch = true, \ - .hw.init = &(struct clk_init_data){ \ - .ops = &clk_rpm_branch_ops, \ - .name = #_name, \ - .parent_names = (const char *[]){ "pxo_board" }, \ - .num_parents = 1, \ - }, \ - }; \ - static struct clk_rpm _platform##_##_active = { \ - .rpm_clk_id = (r_id), \ - .peer = &_platform##_##_name, \ - .rate = (r), \ - .branch = true, \ - .hw.init = &(struct clk_init_data){ \ - .ops = &clk_rpm_branch_ops, \ - .name = #_active, \ - .parent_names = (const char *[]){ "pxo_board" }, \ - .num_parents = 1, \ - }, \ - } - -#define DEFINE_CLK_RPM_CXO_BRANCH (_platform, _name, _active, r_id, r) \ - static struct clk_rpm _platform##_##_active; \ - static struct clk_rpm _platform##_##_name = { \ - .rpm_clk_id = (r_id), \ - .peer = &_platform##_##_active, \ - .rate = (r), \ - .branch = true, \ - .hw.init = &(struct clk_init_data){ \ - .ops = &clk_rpm_branch_ops, \ - .name = #_name, \ - .parent_names = (const char *[]){ "cxo_board" }, \ - .num_parents = 1, \ - }, \ - }; \ - static struct clk_rpm _platform##_##_active = { \ - .rpm_clk_id = (r_id), \ - .active_only = true, \ - .peer = &_platform##_##_name, \ - .rate = (r), \ - .branch = true, \ - .hw.init = &(struct clk_init_data){ \ - .ops = &clk_rpm_branch_ops, \ - .name = #_active, \ - .parent_names = (const char *[]){ "cxo_board" }, \ - .num_parents = 1, \ - }, \ - } -#define to_clk_rpm (_hw) container_of(_hw, struct clk_rpm, hw)struct rpm_cc ;
@@ -450,13 +394,6 @@ static const struct clk_ops clk_rpm_ops = { .recalc_rate = clk_rpm_recalc_rate, }; -static const struct clk_ops clk_rpm_branch_ops = { - .prepare = clk_rpm_prepare, - .unprepare = clk_rpm_unprepare, - .round_rate = clk_rpm_round_rate, - .recalc_rate = clk_rpm_recalc_rate, -}; -/* MSM8660/APQ8060 */ DEFINE_CLK_RPM (msm8660, afab_clk, afab_a_clk,QCOM_RPM_APPS_FABRIC_CLK );DEFINE_CLK_RPM (msm8660, sfab_clk, sfab_a_clk,QCOM_RPM_SYS_FABRIC_CLK );
Signature · 1 line
2.25.1
Re: [PATCH 18/21] clk: qcom: clk-rpm: Remove a bunch of superfluous code
Quoted 10 lines · Lee Jones
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 <[email protected]>Cc Bjorn Andersson <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>
Quoted 89 lines
Signed-off-by Lee Jones <[email protected]>--- drivers/clk/qcom/clk-rpm.c | 63 -------------------------------------- 1 file changed, 63 deletions(-)drivers/clk/qcom/clk-rpm.c +0
-63@@ -73,62 +73,6 @@ }, \ } -#define DEFINE_CLK_RPM_PXO_BRANCH (_platform, _name, _active, r_id, r) \ - static struct clk_rpm _platform##_##_active; \ - static struct clk_rpm _platform##_##_name = { \ - .rpm_clk_id = (r_id), \ - .active_only = true, \ - .peer = &_platform##_##_active, \ - .rate = (r), \ - .branch = true, \ - .hw.init = &(struct clk_init_data){ \ - .ops = &clk_rpm_branch_ops, \ - .name = #_name, \ - .parent_names = (const char *[]){ "pxo_board" }, \ - .num_parents = 1, \ - }, \ - }; \ - static struct clk_rpm _platform##_##_active = { \ - .rpm_clk_id = (r_id), \ - .peer = &_platform##_##_name, \ - .rate = (r), \ - .branch = true, \ - .hw.init = &(struct clk_init_data){ \ - .ops = &clk_rpm_branch_ops, \ - .name = #_active, \ - .parent_names = (const char *[]){ "pxo_board" }, \ - .num_parents = 1, \ - }, \ - } - -#define DEFINE_CLK_RPM_CXO_BRANCH (_platform, _name, _active, r_id, r) \ - static struct clk_rpm _platform##_##_active; \ - static struct clk_rpm _platform##_##_name = { \ - .rpm_clk_id = (r_id), \ - .peer = &_platform##_##_active, \ - .rate = (r), \ - .branch = true, \ - .hw.init = &(struct clk_init_data){ \ - .ops = &clk_rpm_branch_ops, \ - .name = #_name, \ - .parent_names = (const char *[]){ "cxo_board" }, \ - .num_parents = 1, \ - }, \ - }; \ - static struct clk_rpm _platform##_##_active = { \ - .rpm_clk_id = (r_id), \ - .active_only = true, \ - .peer = &_platform##_##_name, \ - .rate = (r), \ - .branch = true, \ - .hw.init = &(struct clk_init_data){ \ - .ops = &clk_rpm_branch_ops, \ - .name = #_active, \ - .parent_names = (const char *[]){ "cxo_board" }, \ - .num_parents = 1, \ - }, \ - } -#define to_clk_rpm (_hw) container_of(_hw, struct clk_rpm, hw)struct rpm_cc ;@@ -450,13 +394,6 @@ static const struct clk_ops clk_rpm_ops = { .recalc_rate = clk_rpm_recalc_rate, }; -static const struct clk_ops clk_rpm_branch_ops = { - .prepare = clk_rpm_prepare, - .unprepare = clk_rpm_unprepare, - .round_rate = clk_rpm_round_rate, - .recalc_rate = clk_rpm_recalc_rate, -}; -/* MSM8660/APQ8060 */ DEFINE_CLK_RPM (msm8660, afab_clk, afab_a_clk,QCOM_RPM_APPS_FABRIC_CLK );DEFINE_CLK_RPM (msm8660, sfab_clk, sfab_a_clk,QCOM_RPM_SYS_FABRIC_CLK );Signature · 1 line
2.25.1
Re: [PATCH 18/21] clk: qcom: clk-rpm: Remove a bunch of superfluous code
In reply to Lee JonesQuoting Lee Jones (2021-01-26 04:45:37)
Quoted 4 lines
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=]
Quoted 8 lines
Cc Andy Gross <[email protected]>Cc Bjorn Andersson <[email protected]>Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Signed-off-by Lee Jones <[email protected]>---
This has been rejected before but OK
Applied to clk-next
PATCH 19/21 clk: spear: Move prototype to accessible header
In reply to Lee JonesFixes 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]
--- arch/arm/mach-spear/generic.h | 12 ------------ arch/arm/mach-spear/spear13xx.c | 1 + drivers/clk/spear/spear1310_clock.c | 1 + drivers/clk/spear/spear1340_clock.c | 1 + include/linux/clk/spear.h | 23 +++++++++++++++++++++++ 5 files changed, 26 insertions(+), 12 deletions(-) create mode 100644 include/linux/clk/spear.h
arch/arm/mach-spear/generic.h +0 -12
@@ -43,16 +43,4 @@ void spear13xx_cpu_die(unsigned int cpu);extern const struct smp_operations spear13xx_smp_ops; -#ifdef CONFIG_MACH_SPEAR1310 -void __init spear1310_clk_init (void __iomem *misc_base,void __iomem *ras_base); -#else -static inline void spear1310_clk_init (void __iomem *misc_base,void __iomem *ras_base) {} -#endif - -#ifdef CONFIG_MACH_SPEAR1340 -void __init spear1340_clk_init (void __iomem *misc_base); -#else -static inline void spear1340_clk_init (void __iomem *misc_base) {} -#endif -#endif /* __MACH_GENERIC_H */
arch/arm/mach-spear/spear13xx.c +1 -0
@@ -15,6 +15,7 @@#include <linux/amba/pl022.h> #include <linux/clk.h> +#include <linux/clk/spear.h> #include <linux/clocksource.h> #include <linux/err.h> #include <linux/of.h>
drivers/clk/spear/spear1310_clock.c +1 -0
@@ -12,6 +12,7 @@*/ #include <linux/clkdev.h> +#include <linux/clk/spear.h> #include <linux/err.h> #include <linux/io.h> #include <linux/of_platform.h>
drivers/clk/spear/spear1340_clock.c +1 -0
@@ -12,6 +12,7 @@*/ #include <linux/clkdev.h> +#include <linux/clk/spear.h> #include <linux/err.h> #include <linux/io.h> #include <linux/of_platform.h>
include/linux/clk/spear.h new file +23 -0
@@ -0,0 +1,23 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* +* Copyright (C) 2020 STMicroelectronics - All Rights Reserved +* +* Author: Lee Jones <[email protected]> +*/ + +#ifndef __LINUX_CLK_SPEAR_H +#define __LINUX_CLK_SPEAR_H + +#ifdef CONFIG_MACH_SPEAR1310 +void __init spear1310_clk_init (void __iomem *misc_base,void __iomem *ras_base); +#else +static inline void spear1310_clk_init (void __iomem *misc_base,void __iomem *ras_base) {} +#endif + +#ifdef CONFIG_MACH_SPEAR1340 +void __init spear1340_clk_init (void __iomem *misc_base); +#else +static inline void spear1340_clk_init (void __iomem *misc_base) {} +#endif + +#endif
Signature · 7 lines
2.25.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 19/21] clk: spear: Move prototype to accessible header
Quoted 11 lines · Lee Jones
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 <[email protected]>Cc Shiraz Hashim <[email protected]>Cc Russell King <[email protected]>Cc Rajeev Kumar <[email protected]>Signed-off-by Lee Jones <[email protected]>
Quoted 8 lines
--- arch/arm/mach-spear/generic.h | 12 ------------ arch/arm/mach-spear/spear13xx.c | 1 + drivers/clk/spear/spear1310_clock.c | 1 + drivers/clk/spear/spear1340_clock.c | 1 + include/linux/clk/spear.h | 23 +++++++++++++++++++++++ 5 files changed, 26 insertions(+), 12 deletions(-) create mode 100644 include/linux/clk/spear.h
Signature · 6 lines
viresh _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 19/21] clk: spear: Move prototype to accessible header
In reply to Lee JonesQuoting Lee Jones (2021-01-26 04:45:38)
Quoted 5 lines
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]
Quoted 7 lines
Cc Viresh Kumar <[email protected]>Cc Shiraz Hashim <[email protected]>Cc Russell King <[email protected]>Cc Rajeev Kumar <[email protected]>Signed-off-by Lee Jones <[email protected]>---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 20/21 clk: imx: Move 'imx6sl_set_wait_clk()'s prototype out to accessible header
In reply to Lee JonesFixes the following W=1 kernel build warning(s):
drivers/clk/imx/clk-imx6sl.c:156:6: warning: no previous prototype for ‘imx6sl_set_wait_clk’ [-Wmissing-prototypes]
--- arch/arm/mach-imx/common.h | 1 - arch/arm/mach-imx/cpuidle-imx6sl.c | 1 + arch/arm/mach-imx/pm-imx6.c | 1 + drivers/clk/imx/clk-imx6sl.c | 1 + include/linux/clk/imx.h | 15 +++++++++++++++ 5 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 include/linux/clk/imx.h
arch/arm/mach-imx/common.h +0 -1
@@ -85,7 +85,6 @@ void imx_anatop_pre_suspend(void);void imx_anatop_post_resume (void );int imx6_set_lpm (enum mxc_cpu_pwr_mode mode);void imx6_set_int_mem_clk_lpm (bool enable); -void imx6sl_set_wait_clk (bool enter);int imx_mmdc_get_ddr_type (void );int imx7ulp_set_lpm (enum ulp_cpu_pwr_mode mode);
arch/arm/mach-imx/cpuidle-imx6sl.c +1 -0
@@ -3,6 +3,7 @@* Copyright (C) 2014 Freescale Semiconductor, Inc. */ +#include <linux/clk/imx.h> #include <linux/cpuidle.h> #include <linux/module.h> #include <asm/cpuidle.h>
arch/arm/mach-imx/pm-imx6.c +1 -0
@@ -4,6 +4,7 @@* Copyright 2011 Linaro Ltd. */ +#include <linux/clk/imx.h> #include <linux/delay.h> #include <linux/init.h> #include <linux/io.h>
drivers/clk/imx/clk-imx6sl.c +1 -0
@@ -6,6 +6,7 @@#include <linux/bits.h> #include <linux/clk.h> #include <linux/clkdev.h> +#include <linux/clk/imx.h> #include <linux/err.h> #include <linux/of.h> #include <linux/of_address.h>
include/linux/clk/imx.h new file +15 -0
@@ -0,0 +1,15 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* +* Copyright (C) 2020 Freescale Semiconductor, Inc. +* +* Author: Lee Jones <[email protected]> +*/ + +#ifndef __LINUX_CLK_IMX_H +#define __LINUX_CLK_IMX_H + +#include <linux/types.h> + +void imx6sl_set_wait_clk (bool enter); + +#endif
Signature · 7 lines
2.25.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Shawn Guo
AppliedRe: [PATCH 20/21] clk: imx: Move 'imx6sl_set_wait_clk()'s prototype out to accessible header
Quoted 4 lines · Lee Jones
Fixes the following W=1 kernel build warning(s):
drivers/clk/imx/clk-imx6sl.c:156:6: warning: no previous prototype for ‘imx6sl_set_wait_clk’ [-Wmissing-prototypes]
Quoted 9 lines
Cc Russell King <[email protected]>Cc Shawn Guo <[email protected]>Cc Sascha Hauer <[email protected]>Cc Pengutronix Kernel Team <[email protected]>Cc Fabio Estevam <[email protected]>Cc NXP Linux Team <[email protected]>Cc Ahmad Fatoum <[email protected]>Signed-off-by Lee Jones <[email protected]>
Applied, thanks.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 21/21 clk: zynqmp: divider: Add missing description for 'max_div'
In reply to Lee JonesFixes 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'
--- drivers/clk/zynqmp/divider.c | 1 + 1 file changed, 1 insertion(+)
drivers/clk/zynqmp/divider.c +1 -0
@@ -35,6 +35,7 @@* @is_frac: The divider is a fractional divider * @clk_id: Id of clock * @div_type: divisor type (TYPE_DIV1 or TYPE_DIV2) +* @max_div: maximum supported divisor (fetched from firmware) */ struct zynqmp_clk_divider {struct clk_hw hw;
Signature · 7 lines
2.25.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 21/21] clk: zynqmp: divider: Add missing description for 'max_div'
Quoted 21 lines · Lee Jones
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 <[email protected]>Cc Stephen Boyd <[email protected]>Cc Michal Simek <[email protected]>Cc Rajan Vaja <[email protected]>Signed-off-by Lee Jones <[email protected]>--- drivers/clk/zynqmp/divider.c | 1 + 1 file changed, 1 insertion(+)drivers/clk/zynqmp/divider.c +0
-0
drivers/clk/zynqmp/divider.c line 41
Quoted 7 lines
drivers/clk/zynqmp/divider.c +1
-0@@ -35,6 +35,7 @@* @is_frac: The divider is a fractional divider * @clk_id: Id of clock * @div_type: divisor type (TYPE_DIV1 or TYPE_DIV2) +* @max_div: maximum supported divisor (fetched from firmware) */ struct zynqmp_clk_divider {struct clk_hw hw;
In our soc tree we have
* @max_div: Maximum divisor value allowed
But your description should be also fine. Rajan please reply if I am wrong. Otherwise:
Thanks,
Michal
Re: [PATCH 21/21] clk: zynqmp: divider: Add missing description for 'max_div'
In reply to Lee JonesQuoting Lee Jones (2021-01-26 04:45:40)
Quoted 4 lines
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'
Quoted 8 lines
Cc Michael Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Cc Michal Simek <[email protected]>Cc Rajan Vaja <[email protected]>Signed-off-by Lee Jones <[email protected]>---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 5 lines · Lee Jones
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings.
This is the last set. Clock is clean after this.
Out of interest, what normally happens to the patches which aren't picked up by individual driver Maintainers?
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Stephen Boyd
maintainerQuoting Lee Jones (2021-02-03 00:31:55)
Quoted 11 lines · Lee Jones
Quoted 6 lines
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings.
This is the last set. Clock is clean after this.
Out of interest, what normally happens to the patches which aren't picked up by individual driver Maintainers?
I have to go in and figure it out! :)
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 7 lines · Stephen Boyd
Quoting Lee Jones (2021-02-03 00:31:55)
Quoted 6 lines · Lee Jones
Quoted 5 lines
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
This is the last set. Clock is clean after this.
Out of interest, what normally happens to the patches which aren't picked up by individual driver Maintainers?
I have to go in and figure it out! :)
Thanks mate, much obliged.
Signature · 9 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 56 lines · Lee Jones
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings.
This is the last set. Clock is clean after this.
Lee Jones (21):
clk: zynq: pll: Fix kernel-doc formatting in 'clk_register_zynq_pll's
header
clk: ti:clkt_dpll: Fix some kernel-doc misdemeanours
clk: ti: dpll3xxx: Fix some kernel-doc headers and promote other
worthy ones
clk: qcom: clk-regmap: Provide missing description for
'devm_clk_register_regmap()'s dev param
clk: sunxi: clk-sun9i-core: Demote non-conformant kernel-doc headers
clk: sunxi: clk-usb: Demote obvious kernel-doc abuse
clk: tegra: clk-tegra30: Remove unused variable 'reg'
clk: clkdev: Ignore suggestion to usegnu_printf()as it's not
appropriate here
clk: tegra: cvb: Provide missing description for
'tegra_cvb_add_opp_table()'s align param
clk: ti: dpll44xx: Fix some potential doc-rot
clk: renesas: renesas-cpg-mssr: Fix formatting issues for
'smstpcr_saved's documentation
clk: sunxi: clk-sun6i-ar100: Demote non-conformant kernel-doc header
clk: qcom: gcc-ipq4019: Remove unused variable 'ret'
clk: clk-fixed-mmio: Demote obvious kernel-doc abuse
clk: clk-npcm7xx: Remove unused static const tables 'npcm7xx_gates'
and 'npcm7xx_divs_fx'
clk: qcom: mmcc-msm8974: Remove unused static const tables'mmcc_xo_mmpll0_1_2_gpll0{map}' clk: clk-xgene: Add description for 'mask' and fix formatting for 'flags'clk: qcom: clk-rpm: Remove a bunch of superfluous code
clk: spear: Move prototype to accessible header
clk: imx: Move 'imx6sl_set_wait_clk()'s prototype out to accessible
header
clk: zynqmp: divider: Add missing description for 'max_div'arch/arm/mach-imx/common.h | 1 - arch/arm/mach-imx/cpuidle-imx6sl.c | 1 + arch/arm/mach-imx/pm-imx6.c | 1 + arch/arm/mach-spear/generic.h | 12 --- arch/arm/mach-spear/spear13xx.c | 1 + drivers/clk/clk-fixed-mmio.c | 2 +- drivers/clk/clk-npcm7xx.c | 108 ------------------------- drivers/clk/clk-xgene.c | 5 +- drivers/clk/clkdev.c | 7 ++ drivers/clk/imx/clk-imx6sl.c | 1 + drivers/clk/qcom/clk-regmap.c | 1 + drivers/clk/qcom/clk-rpm.c | 63 --------------- drivers/clk/qcom/gcc-ipq4019.c | 7 +- drivers/clk/qcom/mmcc-msm8974.c | 16 ---- drivers/clk/renesas/renesas-cpg-mssr.c | 4 +- drivers/clk/spear/spear1310_clock.c | 1 + drivers/clk/spear/spear1340_clock.c | 1 +
Quoted 8 lines
drivers/clk/sunxi/clk-sun6i-ar100.c | 2 +- drivers/clk/sunxi/clk-sun9i-core.c | 8 +- drivers/clk/sunxi/clk-usb.c | 2 +- drivers/clk/tegra/clk-tegra30.c | 5 +- drivers/clk/tegra/cvb.c | 1 + drivers/clk/ti/clkt_dpll.c | 3 +- drivers/clk/ti/dpll3xxx.c | 20 ++--- drivers/clk/ti/dpll44xx.c | 6 +-
For the TI portions:
Quoted 55 lines
drivers/clk/zynq/pll.c | 12 +-- drivers/clk/zynqmp/divider.c | 1 + include/linux/clk/imx.h | 15 ++++ include/linux/clk/spear.h | 23 ++++++ 29 files changed, 92 insertions(+), 238 deletions(-)create mode 100644
include/linux/clk/imx.hcreate mode 100644include/linux/clk/spear.hCc Ahmad Fatoum <[email protected]>Cc Andy Gross <[email protected]>Cc Avi Fishman <[email protected]>Cc Benjamin Fair <[email protected]>Cc Bjorn Andersson <[email protected]>Cc Boris BREZILLON <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc "Emilio López" <[email protected]>Cc Fabio Estevam <[email protected]>Cc Geert Uytterhoeven <[email protected]>Cc Jan Kotas <[email protected]>Cc Jernej Skrabec <[email protected]>Cc Jonathan Hunter <[email protected]>Cc Loc Ho <[email protected]>Cc Maxime Ripard <[email protected]>Cc Michael Turquette <[email protected]>Cc Michal Simek <[email protected]>Cc Nancy Yuen <[email protected]>Cc Nuvoton Technologies <[email protected]>Cc NXP Linux Team <[email protected]>Cc Patrick Venture <[email protected]>Cc Pengutronix Kernel Team <[email protected]>Cc Peter De Schrijver <[email protected]>Cc Philipp Zabel <[email protected]>Cc Prashant Gaikwad <[email protected]>Cc Rajan Vaja <[email protected]>Cc Rajeev Kumar <[email protected]>Cc Richard Woodruff <[email protected]>Cc Russell King <[email protected]>Cc Sascha Hauer <[email protected]>Cc Shawn Guo <[email protected]>Cc Shiraz Hashim <[email protected]>Cc "Sören Brinkmann" <[email protected]>Cc Stephen Boyd <[email protected]>Cc Tali Perry <[email protected]>Cc Tero Kristo <[email protected]>Cc Thierry Reding <[email protected]>Cc Tomer Maimon <[email protected]>Cc Viresh Kumar <[email protected]>
Stephen Boyd
maintainerQuoting Lee Jones (2021-01-26 04:45:19)
Quoted 5 lines
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings.
This is the last set. Clock is clean after this.
Is it possible to slam in some patch that makes W=1 the default for the clk directory? I'm trying to avoid seeing this patch series again.
Quoted 9 lines · Stephen Boyd
Quoting Lee Jones (2021-01-26 04:45:19)
Quoted 5 lines
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings.
This is the last set. Clock is clean after this.
Is it possible to slam in some patch that makes W=1 the default for the clk directory? I'm trying to avoid seeing this patch series again.
One of my main goals of this project is that everyone (contributors, maintainers auto-builder robots etc) will be enabling W=1 builds *locally*.
This isn't something you'll want to do at a global (i.e. in Mainline) level. That's kinda the point of W=1.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Stephen Boyd
maintainerQuoting Lee Jones (2021-02-11 13:10:54)
Quoted 12 lines · Stephen Boyd
Quoted 10 lines
Quoting Lee Jones (2021-01-26 04:45:19)
Quoted 5 lines
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings.
This is the last set. Clock is clean after this.
Is it possible to slam in some patch that makes W=1 the default for the clk directory? I'm trying to avoid seeing this patch series again.
Quoted 7 lines
One of my main goals of this project is that everyone (contributors, maintainers auto-builder robots etc) will be enabling W=1 builds *locally*.
This isn't something you'll want to do at a global (i.e. in Mainline) level. That's kinda the point of W=1.
Agreed, but is it possible to pass W=1 in the drivers/clk/Makefile?
Quoted 17 lines · Stephen Boyd
Quoting Lee Jones (2021-02-11 13:10:54)
Quoted 16 lines · Stephen Boyd
Quoted 10 lines
Quoting Lee Jones (2021-01-26 04:45:19)
Quoted 5 lines
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings.
This is the last set. Clock is clean after this.
Is it possible to slam in some patch that makes W=1 the default for the clk directory? I'm trying to avoid seeing this patch series again.
One of my main goals of this project is that everyone (contributors, maintainers auto-builder robots etc) will be enabling W=1 builds *locally*.
Quoted 5 lines
Quoted 3 lines
This isn't something you'll want to do at a global (i.e. in Mainline) level. That's kinda the point of W=1.
Agreed, but is it possible to pass W=1 in the
drivers/clk/Makefile?
That would circumvent the point of W=1. Level-1 warnings are deemed, and I'm paraphrasing/making this up "not worth rejecting pull-requests over". In contrast, if Linus catches any W=0 warnings at pull-time, he will reject the pull-request as 'untested'.
W=1 is defiantly something you'll want to enable locally though, and subsequently push back on contributors submitting code adding new ones.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Stephen Boyd
maintainerQuoting Lee Jones (2021-02-12 01:20:16)
Quoted 25 lines · Stephen Boyd
Quoted 18 lines
Quoting Lee Jones (2021-02-11 13:10:54)
Quoted 16 lines · Stephen Boyd
Quoted 10 lines
Quoting Lee Jones (2021-01-26 04:45:19)
Quoted 5 lines
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings.
This is the last set. Clock is clean after this.
Is it possible to slam in some patch that makes W=1 the default for the clk directory? I'm trying to avoid seeing this patch series again.
One of my main goals of this project is that everyone (contributors, maintainers auto-builder robots etc) will be enabling W=1 builds *locally*.
Quoted 5 lines
Quoted 3 lines
This isn't something you'll want to do at a global (i.e. in Mainline) level. That's kinda the point of W=1.
Agreed, but is it possible to pass W=1 in the
drivers/clk/Makefile?
Quoted 9 lines
That would circumvent the point of W=1. Level-1 warnings are deemed, and I'm paraphrasing/making this up "not worth rejecting pull-requests over". In contrast, if Linus catches any W=0 warnings at pull-time, he will reject the pull-request as 'untested'.
W=1 is defiantly something you'll want to enable locally though, and subsequently push back on contributors submitting code adding new ones.
Why should I install a land mine for others to trip over? Won't that just take them more time because they won't know to compile with W=1 and then will have to go for another round of review while I push back on them submitting new warnings?
Quoted 36 lines · Stephen Boyd
Quoting Lee Jones (2021-02-12 01:20:16)
Quoted 25 lines · Stephen Boyd
Quoted 18 lines
Quoting Lee Jones (2021-02-11 13:10:54)
Quoted 16 lines · Stephen Boyd
Quoted 10 lines
Quoting Lee Jones (2021-01-26 04:45:19)
Quoted 5 lines
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings.
This is the last set. Clock is clean after this.
Is it possible to slam in some patch that makes W=1 the default for the clk directory? I'm trying to avoid seeing this patch series again.
One of my main goals of this project is that everyone (contributors, maintainers auto-builder robots etc) will be enabling W=1 builds *locally*.
Quoted 5 lines
Quoted 3 lines
This isn't something you'll want to do at a global (i.e. in Mainline) level. That's kinda the point of W=1.
Agreed, but is it possible to pass W=1 in the
drivers/clk/Makefile?Quoted 9 lines
That would circumvent the point of W=1. Level-1 warnings are deemed, and I'm paraphrasing/making this up "not worth rejecting pull-requests over". In contrast, if Linus catches any W=0 warnings at pull-time, he will reject the pull-request as 'untested'.
W=1 is defiantly something you'll want to enable locally though, and subsequently push back on contributors submitting code adding new ones.
Quoted 4 lines
Why should I install a land mine for others to trip over? Won't that just take them more time because they won't know to compile with W=1 and then will have to go for another round of review while I push back on them submitting new warnings?
The alternative is to not worry about it and review the slow drip of fixes that will occur as a result. The issues I just fixed were built up over years. They won't get to that level again.
In my mind contributors should be compiling their submissions with W=1 enabled by default. I'm fairly sure the auto-builders do this now.
Once W=1 warnings are down to an acceptable level in the kernel as a whole, we can provide some guidance in SubmittingPatches (or similar) on how to enable them (hint: you add "W=1" on the compile line).
Enabling W=1 in the default build will only serve to annoy Linus IMHO. If he wants them to be enabled by default, they wouldn't be W=1 in the first place, they'd be W=0 which *is* the default build.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Quoted 50 lines · Lee Jones
Quoted 36 lines · Stephen Boyd
Quoting Lee Jones (2021-02-12 01:20:16)
Quoted 25 lines · Stephen Boyd
Quoted 18 lines
Quoting Lee Jones (2021-02-11 13:10:54)
Quoted 16 lines · Stephen Boyd
Quoted 10 lines
Quoting Lee Jones (2021-01-26 04:45:19)
Quoted 5 lines
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings.
This is the last set. Clock is clean after this.
Is it possible to slam in some patch that makes W=1 the default for the clk directory? I'm trying to avoid seeing this patch series again.
One of my main goals of this project is that everyone (contributors, maintainers auto-builder robots etc) will be enabling W=1 builds *locally*.
Quoted 5 lines
Quoted 3 lines
This isn't something you'll want to do at a global (i.e. in Mainline) level. That's kinda the point of W=1.
Agreed, but is it possible to pass W=1 in the
drivers/clk/Makefile?Quoted 9 lines
That would circumvent the point of W=1. Level-1 warnings are deemed, and I'm paraphrasing/making this up "not worth rejecting pull-requests over". In contrast, if Linus catches any W=0 warnings at pull-time, he will reject the pull-request as 'untested'.
W=1 is defiantly something you'll want to enable locally though, and subsequently push back on contributors submitting code adding new ones.
Quoted 4 lines
Why should I install a land mine for others to trip over? Won't that just take them more time because they won't know to compile with W=1 and then will have to go for another round of review while I push back on them submitting new warnings?
The alternative is to not worry about it and review the slow drip of fixes that will occur as a result. The issues I just fixed were built up over years. They won't get to that level again.
In my mind contributors should be compiling their submissions with W=1 enabled by default. I'm fairly sure the auto-builders do this now.
Quoted 7 lines
Once W=1 warnings are down to an acceptable level in the kernel as a whole, we can provide some guidance in SubmittingPatches (or similar) on how to enable them (hint: you add "W=1" on the compile line).
Enabling W=1 in the default build will only serve to annoy Linus IMHO. If he wants them to be enabled by default, they wouldn't be W=1 in the first place, they'd be W=0 which *is* the default build.
Just to add real quick - my advice is to enable them for yourself and send back any issues along with your normal review. A W=1 issue is no different to a semantic or coding style one.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Stephen Boyd
maintainerQuoting Lee Jones (2021-02-12 13:26:30)
Quoted 8 lines · Lee Jones
Quoted 7 lines
The alternative is to not worry about it and review the slow drip of fixes that will occur as a result. The issues I just fixed were built up over years. They won't get to that level again.
In my mind contributors should be compiling their submissions with W=1 enabled by default. I'm fairly sure the auto-builders do this now.
That's good.
Quoted 5 lines
Quoted 5 lines
Once W=1 warnings are down to an acceptable level in the kernel as a whole, we can provide some guidance in SubmittingPatches (or similar) on how to enable them (hint: you add "W=1" on the compile line).
Quoted 8 lines
Quoted 3 lines
Enabling W=1 in the default build will only serve to annoy Linus IMHO. If he wants them to be enabled by default, they wouldn't be W=1 in the first place, they'd be W=0 which *is* the default build.
Just to add real quick - my advice is to enable them for yourself and send back any issues along with your normal review. A W=1 issue is no different to a semantic or coding style one.
I'd like to enable it for only files under drivers/clk/ but it doesn't seem to work. I'm not asking to enable it at the toplevel Makefile. I'm asking to enable it for drivers/clk/ so nobody has to think about it now that you've done the hard work of getting the numbers in this directory down to zero or close to zero.
Quoted 26 lines · Stephen Boyd
Quoting Lee Jones (2021-02-12 13:26:30)
Quoted 8 lines · Lee Jones
Quoted 7 lines
The alternative is to not worry about it and review the slow drip of fixes that will occur as a result. The issues I just fixed were built up over years. They won't get to that level again.
In my mind contributors should be compiling their submissions with W=1 enabled by default. I'm fairly sure the auto-builders do this now.
That's good.
Quoted 5 lines
Quoted 5 lines
Once W=1 warnings are down to an acceptable level in the kernel as a whole, we can provide some guidance in SubmittingPatches (or similar) on how to enable them (hint: you add "W=1" on the compile line).
Quoted 8 lines
Quoted 3 lines
Enabling W=1 in the default build will only serve to annoy Linus IMHO. If he wants them to be enabled by default, they wouldn't be W=1 in the first place, they'd be W=0 which *is* the default build.
Just to add real quick - my advice is to enable them for yourself and send back any issues along with your normal review. A W=1 issue is no different to a semantic or coding style one.
Quoted 5 lines
I'd like to enable it for only files under
drivers/clk/but it doesn't seem to work. I'm not asking to enable it at the toplevelMakefile. I'm asking to enable it fordrivers/clk/so nobody has to think about it now that you've done the hard work of getting the numbers in this directory down to zero or close to zero.
I'm not sure which one of us is confused. Probably me, but ...
Even if you could enable it per-subsystem, how would that help you?
How can you ensure that contributors see any new W=1 warnings, but Linus doesn't? When Linus conducts his build-tests during the merge window, he is also going to build W=1 for drivers/clk.
All that's going to achieve is put you in the firing line.
From my PoV W=1 builds should be enabled during the development phase (i.e. contributor, auto-builder, maintainer). By the time patches get make it into Mainline the review/testing stage is over and only the default W=0 warnings are meaningful.
Signature · 9 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Stephen Boyd
maintainerQuoting Lee Jones (2021-02-12 14:37:39)
Quoted 9 lines · Stephen Boyd
Quoted 7 lines
I'd like to enable it for only files under
drivers/clk/but it doesn't seem to work. I'm not asking to enable it at the toplevelMakefile. I'm asking to enable it fordrivers/clk/so nobody has to think about it now that you've done the hard work of getting the numbers in this directory down to zero or close to zero.
Quoted 7 lines
I'm not sure which one of us is confused. Probably me, but ...
Even if you could enable it per-subsystem, how would that help you?
How can you ensure that contributors see any new W=1 warnings, but Linus doesn't? When Linus conducts his build-tests during the merge window, he is also going to build W=1 for
drivers/clk.
The assumption is contributors would have compiled the code they're sending, but that's obviously not always the case, so this assumption relies on developers running make. If they do run make then the hope is they would see the warnings now, without having to rely on them to know about passing W=1 to make, and fix them before sending code. If developers are ignoring build errors or warnings then we can't do anything anyway.
Quoted 2 lines
All that's going to achieve is put you in the firing line.
Ok. Is this prior experience?
Quoted 6 lines
From my PoV W=1 builds should be enabled during the development phase (i.e. contributor, auto-builder, maintainer). By the time patches get make it into Mainline the review/testing stage is over and only the default W=0 warnings are meaningful.
Alright maybe I don't understand and W=1 builds are noisy for the drivers/clk subdirectory even after applying these patches. Or it has some false positives that won't be fixed? Or a new compiler can cause new warnings to happen? I could see these things being a problem.
I'm trying to see if we can make lives better for everyone by exposing the warnings by default in the drivers/clk/ directory now that there are supposedly none left. Shouldn't we tighten the screws now that we've cleaned them?
Quoted 4 lines
I'm trying to see if we can make lives better for everyone by exposing the warnings by default in the
drivers/clk/directory now that there are supposedly none left. Shouldn't we tighten the screws now that we've cleaned them?
Do you use patchwork? netdev has a bot attached which applies the patch and does a W=1 build, and will report any new warnings. But it does not email the developer, as far as i know. It is up to you as the maintainer to reject the patch and say why.
Andrew
Stephen Boyd
maintainerQuoting Andrew Lunn (2021-02-13 08:04:34)
Quoted 10 lines
Quoted 4 lines
I'm trying to see if we can make lives better for everyone by exposing the warnings by default in the
drivers/clk/directory now that there are supposedly none left. Shouldn't we tighten the screws now that we've cleaned them?Do you use patchwork? netdev has a bot attached which applies the patch and does a W=1 build, and will report any new warnings. But it does not email the developer, as far as i know. It is up to you as the maintainer to reject the patch and say why.
Yes the kernel.org patchwork instance is used but I don't see any bot putting test results there. How is that done?
Quoted 12 lines · Stephen Boyd
Quoting Andrew Lunn (2021-02-13 08:04:34)
Quoted 10 lines
Quoted 4 lines
I'm trying to see if we can make lives better for everyone by exposing the warnings by default in the
drivers/clk/directory now that there are supposedly none left. Shouldn't we tighten the screws now that we've cleaned them?Do you use patchwork? netdev has a bot attached which applies the patch and does a W=1 build, and will report any new warnings. But it does not email the developer, as far as i know. It is up to you as the maintainer to reject the patch and say why.
Quoted 4 lines
Yes the kernel.org patchwork instance is used but I don't see any bot putting test results there. How is that done?
Compare this with for example:
https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/
Jakub can explain how he added these checks.
Andrew
Quoted 13 lines · Andrew Lunn
Quoted 12 lines · Stephen Boyd
Quoting Andrew Lunn (2021-02-13 08:04:34)
Quoted 10 lines
Quoted 4 lines
I'm trying to see if we can make lives better for everyone by exposing the warnings by default in the
drivers/clk/directory now that there are supposedly none left. Shouldn't we tighten the screws now that we've cleaned them?Do you use patchwork? netdev has a bot attached which applies the patch and does a W=1 build, and will report any new warnings. But it does not email the developer, as far as i know. It is up to you as the maintainer to reject the patch and say why.
Quoted 8 lines
Quoted 4 lines
Yes the kernel.org patchwork instance is used but I don't see any bot putting test results there. How is that done?
Compare this with for example:
https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/
Oh, that's nice.
Quoted 1 line
Jakub can explain how he added these checks.
Yes, please share.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Quoted 3 lines · On Mon, 15 Feb 2021 08:49:52 +0000 Lee Jones wrote:
Quoted 1 line
Jakub can explain how he added these checks.
Yes, please share.
https://github.com/kuba-moo/nipa
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 6 lines · Jakub Kicinski
Quoted 3 lines · On Mon, 15 Feb 2021 08:49:52 +0000 Lee Jones wrote:
Quoted 1 line
Jakub can explain how he added these checks.
Yes, please share.
Thanks for this.
Oh, I see. So you conduct tests locally, then post them up in a section called 'Checks' using the provided API. I assume that Patchwork does not alert the user when something has gone awry? Is this something Nipa does?
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Quoted 10 lines · On Tue, 16 Feb 2021 08:20:46 +0000 Lee Jones wrote:
Quoted 4 lines · Jakub Kicinski
Quoted 1 line · On Mon, 15 Feb 2021 08:49:52 +0000 Lee Jones wrote:
Yes, please share.
Thanks for this.
Oh, I see. So you conduct tests locally, then post them up in a section called 'Checks' using the provided API.
For some definition of "locally" - NIPA runs on a rented VM.
Quoted 2 lines
I assume that Patchwork does not alert the user when something has gone awry? Is this something Nipa does?
The way we run it on netdev is maintainer-centric, IOW we see the failures in patchwork and complain to people manually. The netdev mailing list gets too many messages as is, if NIPA responded with results automatically (which is not that hard technically) my concern is that people would be more likely to send untested patches to the mailing list and rely on the bot.
Quoted 5 lines · Jakub Kicinski
Quoted 4 lines · On Tue, 16 Feb 2021 08:20:46 +0000 Lee Jones wrote:
Quoted 3 lines · Jakub Kicinski
Quoted 1 line · On Mon, 15 Feb 2021 08:49:52 +0000 Lee Jones wrote:
Yes, please share.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Thanks for this.
Oh, I see. So you conduct tests locally, then post them up in a section called 'Checks' using the provided API.
For some definition of "locally" - NIPA runs on a rented VM.
Right. Infrastructure that you control vs by Patchwork.
Quoted 9 lines
Quoted 2 lines
I assume that Patchwork does not alert the user when something has gone awry? Is this something Nipa does?
The way we run it on netdev is maintainer-centric, IOW we see the failures in patchwork and complain to people manually. The netdev mailing list gets too many messages as is, if NIPA responded with results automatically (which is not that hard technically) my concern is that people would be more likely to send untested patches to the mailing list and rely on the bot.
That makes sense. Thank you for the explanation.
Signature · 9 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 17 lines · Stephen Boyd
Quoting Lee Jones (2021-02-11 13:10:54)
Quoted 16 lines · Stephen Boyd
Quoted 10 lines
Quoting Lee Jones (2021-01-26 04:45:19)
Quoted 5 lines
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings.
This is the last set. Clock is clean after this.
Is it possible to slam in some patch that makes W=1 the default for the clk directory? I'm trying to avoid seeing this patch series again.
One of my main goals of this project is that everyone (contributors, maintainers auto-builder robots etc) will be enabling W=1 builds *locally*.
Quoted 5 lines
Quoted 3 lines
This isn't something you'll want to do at a global (i.e. in Mainline) level. That's kinda the point of W=1.
Agreed, but is it possible to pass W=1 in the
drivers/clk/Makefile?
About a cycle ago, Arnd and i played around with this idea. The Ethernet PHY subsystem is W=1 clean, and most of he network stack is. But keeping it clean is not so easy, when developers do sometimes add new warnings, since they have no idea the code is W=1 clean.
You are also not the only one asking for such a feature. RDMA also asked recently.
Arnd, do you plan to push the patches?
Andrew