[PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[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 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

Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: Andy Gross <agross@kernel.org>
Cc: Avi Fishman <avifishman70@gmail.com>
Cc: Benjamin Fair <benjaminfair@google.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Boris BREZILLON <boris.brezillon@free-electrons.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: "Emilio López" <emilio@elopez.com.ar>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Jan Kotas <jank@cadence.com>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Cc: Loc Ho <lho@apm.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Nancy Yuen <yuenn@google.com>
Cc: Nuvoton Technologies <tali.perry@nuvoton.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: openbmc@lists.ozlabs.org
Cc: Patrick Venture <venture@google.com>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Prashant Gaikwad <pgaikwad@nvidia.com>
Cc: Rajan Vaja <rajan.vaja@xilinx.com>
Cc: Rajeev Kumar <rajeev-dlh.kumar@st.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Shiraz Hashim <shiraz.linux.kernel@gmail.com>
Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Tali Perry <tali.perry1@gmail.com>
Cc: Tero Kristo <kristo@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Tomer Maimon <tmaimon77@gmail.com>
Cc: Viresh Kumar <vireshk@kernel.org>
-- 
2.25.1

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

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/clk/ti/clkt_dpll.c:284: warning: Function parameter or member 'hw' not described in 'omap2_dpll_round_rate'
 drivers/clk/ti/clkt_dpll.c:284: warning: Function parameter or member 'parent_rate' not described in 'omap2_dpll_round_rate'
 drivers/clk/ti/clkt_dpll.c:284: warning: Excess function parameter 'clk' description in 'omap2_dpll_round_rate'

Cc: Tero Kristo <kristo@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/clk/ti/clkt_dpll.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/ti/clkt_dpll.c b/drivers/clk/ti/clkt_dpll.c
index 87ece6cd4226b..dfaa4d1f0b64b 100644
--- a/drivers/clk/ti/clkt_dpll.c
+++ b/drivers/clk/ti/clkt_dpll.c
@@ -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
-- 
2.25.1

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

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/clk/ti/dpll3xxx.c:414: warning: Function parameter or member 'hw' not described in 'omap3_dpll_recalc'
 drivers/clk/ti/dpll3xxx.c:414: warning: Function parameter or member 'parent_rate' not described in 'omap3_dpll_recalc'
 drivers/clk/ti/dpll3xxx.c:414: warning: Excess function parameter 'clk' description in 'omap3_dpll_recalc'
 drivers/clk/ti/dpll3xxx.c:437: warning: Function parameter or member 'hw' not described in 'omap3_noncore_dpll_enable'
 drivers/clk/ti/dpll3xxx.c:437: warning: Excess function parameter 'clk' description in 'omap3_noncore_dpll_enable'
 drivers/clk/ti/dpll3xxx.c:479: warning: Function parameter or member 'hw' not described in 'omap3_noncore_dpll_disable'
 drivers/clk/ti/dpll3xxx.c:479: warning: Excess function parameter 'clk' description in 'omap3_noncore_dpll_disable'
 drivers/clk/ti/dpll3xxx.c:755: warning: Function parameter or member 'hw' not described in 'omap3_clkoutx2_recalc'
 drivers/clk/ti/dpll3xxx.c:755: warning: Function parameter or member 'parent_rate' not described in 'omap3_clkoutx2_recalc'
 drivers/clk/ti/dpll3xxx.c:755: warning: Excess function parameter 'clk' description in 'omap3_clkoutx2_recalc'

Cc: Tero Kristo <kristo@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-omap@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/clk/ti/dpll3xxx.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/ti/dpll3xxx.c b/drivers/clk/ti/dpll3xxx.c
index 2490026948b47..6097b099a5dff 100644
--- a/drivers/clk/ti/dpll3xxx.c
+++ b/drivers/clk/ti/dpll3xxx.c
@@ -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
-- 
2.25.1

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

[Lee Jones]

Fixes the following W=1 kernel build warning(s):

 drivers/clk/ti/dpll44xx.c:114: warning: Function parameter or member 'hw' not described in 'omap4_dpll_regm4xen_recalc'
 drivers/clk/ti/dpll44xx.c:114: warning: Function parameter or member 'parent_rate' not described in 'omap4_dpll_regm4xen_recalc'
 drivers/clk/ti/dpll44xx.c:114: warning: Excess function parameter 'clk' description in 'omap4_dpll_regm4xen_recalc'
 drivers/clk/ti/dpll44xx.c:150: warning: Function parameter or member 'hw' not described in 'omap4_dpll_regm4xen_round_rate'
 drivers/clk/ti/dpll44xx.c:150: warning: Function parameter or member 'parent_rate' not described in 'omap4_dpll_regm4xen_round_rate'
 drivers/clk/ti/dpll44xx.c:150: warning: Excess function parameter 'clk' description in 'omap4_dpll_regm4xen_round_rate'

Cc: Tero Kristo <kristo@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-omap@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/clk/ti/dpll44xx.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/ti/dpll44xx.c b/drivers/clk/ti/dpll44xx.c
index 89c3ed1a24b82..3fc2cab69a3fe 100644
--- a/drivers/clk/ti/dpll44xx.c
+++ b/drivers/clk/ti/dpll44xx.c
@@ -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
-- 
2.25.1

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Lee Jones]

On Tue, 26 Jan 2021, Lee Jones wrote:

> 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?

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Stephen Boyd]

Quoting Lee Jones (2021-02-03 00:31:55)
> On Tue, 26 Jan 2021, Lee Jones wrote:
> 
> > 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! :)

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Lee Jones]

On Fri, 05 Feb 2021, Stephen Boyd wrote:

> Quoting Lee Jones (2021-02-03 00:31:55)
> > On Tue, 26 Jan 2021, Lee Jones wrote:
> > 
> > > 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! :)

Thanks mate, much obliged.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Tero Kristo]

On 26/01/2021 14:45, Lee Jones wrote:
> 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 +-

For the TI portions:

Reviewed-by: Tero Kristo <kristo@kernel.org>

>   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
> 
> Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Cc: Andy Gross <agross@kernel.org>
> Cc: Avi Fishman <avifishman70@gmail.com>
> Cc: Benjamin Fair <benjaminfair@google.com>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Boris BREZILLON <boris.brezillon@free-electrons.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: "Emilio López" <emilio@elopez.com.ar>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Jan Kotas <jank@cadence.com>
> Cc: Jernej Skrabec <jernej.skrabec@siol.net>
> Cc: Jonathan Hunter <jonathanh@nvidia.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-arm-msm@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-omap@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-tegra@vger.kernel.org
> Cc: Loc Ho <lho@apm.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: Nancy Yuen <yuenn@google.com>
> Cc: Nuvoton Technologies <tali.perry@nuvoton.com>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> Cc: openbmc@lists.ozlabs.org
> Cc: Patrick Venture <venture@google.com>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Peter De Schrijver <pdeschrijver@nvidia.com>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Prashant Gaikwad <pgaikwad@nvidia.com>
> Cc: Rajan Vaja <rajan.vaja@xilinx.com>
> Cc: Rajeev Kumar <rajeev-dlh.kumar@st.com>
> Cc: Richard Woodruff <r-woodruff2@ti.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Shiraz Hashim <shiraz.linux.kernel@gmail.com>
> Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Tali Perry <tali.perry1@gmail.com>
> Cc: Tero Kristo <kristo@kernel.org>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Tomer Maimon <tmaimon77@gmail.com>
> Cc: Viresh Kumar <vireshk@kernel.org>
> 

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

[Stephen Boyd]

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

Applied to clk-next

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

[Stephen Boyd]

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

Applied to clk-next

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

[Stephen Boyd]

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

Applied to clk-next

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Stephen Boyd]

Quoting Lee Jones (2021-01-26 04:45:19)
> 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.

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Lee Jones]

On Thu, 11 Feb 2021, Stephen Boyd wrote:

> Quoting Lee Jones (2021-01-26 04:45:19)
> > 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.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Stephen Boyd]

Quoting Lee Jones (2021-02-11 13:10:54)
> On Thu, 11 Feb 2021, Stephen Boyd wrote:
> 
> > Quoting Lee Jones (2021-01-26 04:45:19)
> > > 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.
> 

Agreed, but is it possible to pass W=1 in the drivers/clk/Makefile?

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Lee Jones]

On Thu, 11 Feb 2021, Stephen Boyd wrote:

> Quoting Lee Jones (2021-02-11 13:10:54)
> > On Thu, 11 Feb 2021, Stephen Boyd wrote:
> > 
> > > Quoting Lee Jones (2021-01-26 04:45:19)
> > > > 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.
> > 
> 
> 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.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Stephen Boyd]

Quoting Lee Jones (2021-02-12 01:20:16)
> On Thu, 11 Feb 2021, Stephen Boyd wrote:
> 
> > Quoting Lee Jones (2021-02-11 13:10:54)
> > > On Thu, 11 Feb 2021, Stephen Boyd wrote:
> > > 
> > > > Quoting Lee Jones (2021-01-26 04:45:19)
> > > > > 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.
> > > 
> > 
> > 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.
> 

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?

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Lee Jones]

On Fri, 12 Feb 2021, Stephen Boyd wrote:

> Quoting Lee Jones (2021-02-12 01:20:16)
> > On Thu, 11 Feb 2021, Stephen Boyd wrote:
> > 
> > > Quoting Lee Jones (2021-02-11 13:10:54)
> > > > On Thu, 11 Feb 2021, Stephen Boyd wrote:
> > > > 
> > > > > Quoting Lee Jones (2021-01-26 04:45:19)
> > > > > > 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.
> > > > 
> > > 
> > > 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.
> > 
> 
> 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.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Lee Jones]

On Fri, 12 Feb 2021, Lee Jones wrote:

> On Fri, 12 Feb 2021, Stephen Boyd wrote:
> 
> > Quoting Lee Jones (2021-02-12 01:20:16)
> > > On Thu, 11 Feb 2021, Stephen Boyd wrote:
> > > 
> > > > Quoting Lee Jones (2021-02-11 13:10:54)
> > > > > On Thu, 11 Feb 2021, Stephen Boyd wrote:
> > > > > 
> > > > > > Quoting Lee Jones (2021-01-26 04:45:19)
> > > > > > > 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.
> > > > > 
> > > > 
> > > > 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.
> > > 
> > 
> > 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.

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.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Stephen Boyd]

Quoting Lee Jones (2021-02-12 13:26:30)
> On Fri, 12 Feb 2021, Lee Jones wrote:
> 
> > 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.

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

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.

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Lee Jones]

On Fri, 12 Feb 2021, Stephen Boyd wrote:

> Quoting Lee Jones (2021-02-12 13:26:30)
> > On Fri, 12 Feb 2021, Lee Jones wrote:
> > 
> > > 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.
> 
> > > 
> > > 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.
> > 
> 
> 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.

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.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Stephen Boyd]

Quoting Lee Jones (2021-02-12 14:37:39)
> On Fri, 12 Feb 2021, Stephen Boyd wrote:
> 
> > 
> > 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.
> 
> 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.

> 
> All that's going to achieve is put you in the firing line.

Ok. Is this prior experience?

> 
> 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?

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Andrew Lunn]

On Thu, Feb 11, 2021 at 07:07:30PM -0800, Stephen Boyd wrote:
> Quoting Lee Jones (2021-02-11 13:10:54)
> > On Thu, 11 Feb 2021, Stephen Boyd wrote:
> > 
> > > Quoting Lee Jones (2021-01-26 04:45:19)
> > > > 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.
> > 
> 
> 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

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Andrew Lunn]

> 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

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Andrew Lunn]

On Sun, Feb 14, 2021 at 01:00:42PM -0800, Stephen Boyd wrote:
> Quoting Andrew Lunn (2021-02-13 08:04:34)
> > > 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?
> 
> https://patchwork.kernel.org/project/linux-clk/list/

Compare this with for example:

https://patchwork.kernel.org/project/netdevbpf/patch/20210213175257.28642-1-ap420073@gmail.com/

Jakub can explain how he added these checks.

      Andrew

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Lee Jones]

On Sun, 14 Feb 2021, Andrew Lunn wrote:

> On Sun, Feb 14, 2021 at 01:00:42PM -0800, Stephen Boyd wrote:
> > Quoting Andrew Lunn (2021-02-13 08:04:34)
> > > > 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?
> > 
> > https://patchwork.kernel.org/project/linux-clk/list/
> 
> Compare this with for example:
> 
> https://patchwork.kernel.org/project/netdevbpf/patch/20210213175257.28642-1-ap420073@gmail.com/

Oh, that's nice.

> Jakub can explain how he added these checks.

Yes, please share.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Jakub Kicinski]

On Mon, 15 Feb 2021 08:49:52 +0000 Lee Jones wrote:
> > Jakub can explain how he added these checks.  
> 
> Yes, please share.

https://github.com/kuba-moo/nipa

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Lee Jones]

On Mon, 15 Feb 2021, Jakub Kicinski wrote:

> On Mon, 15 Feb 2021 08:49:52 +0000 Lee Jones wrote:
> > > Jakub can explain how he added these checks.  
> > 
> > Yes, please share.
> 
> https://github.com/kuba-moo/nipa

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?

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Jakub Kicinski]

On Tue, 16 Feb 2021 08:20:46 +0000 Lee Jones wrote:
> On Mon, 15 Feb 2021, Jakub Kicinski wrote:
> > On Mon, 15 Feb 2021 08:49:52 +0000 Lee Jones wrote:  
> > > Yes, please share.  
> > 
> > https://github.com/kuba-moo/nipa  
> 
> 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.

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

Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock

[Lee Jones]

On Wed, 17 Feb 2021, Jakub Kicinski wrote:

> On Tue, 16 Feb 2021 08:20:46 +0000 Lee Jones wrote:
> > On Mon, 15 Feb 2021, Jakub Kicinski wrote:
> > > On Mon, 15 Feb 2021 08:49:52 +0000 Lee Jones wrote:  
> > > > Yes, please share.  
> > > 
> > > https://github.com/kuba-moo/nipa  
> > 
> > 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.

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

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog