Thread (39 messages) 39 messages, 8 authors, 2021-03-10

Re: [PATCH 12/21] clk: sunxi: clk-sun6i-ar100: Demote non-conformant kernel-doc header

From: Lee Jones <hidden>
Date: 2021-01-26 18:11:14
Also in: linux-clk, lkml

On Tue, 26 Jan 2021, Maxime Ripard wrote:
On Tue, Jan 26, 2021 at 12:45:31PM +0000, Lee Jones wrote:
quoted
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" <emilio@elopez.com.ar>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Chen-Yu Tsai <redacted>
Cc: Jernej Skrabec <redacted>
Cc: Boris BREZILLON <redacted>
Cc: linux-clk@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Lee Jones <redacted>
---
 drivers/clk/sunxi/clk-sun6i-ar100.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi/clk-sun6i-ar100.c b/drivers/clk/sunxi/clk-sun6i-ar100.c
index e1b7d0929cf7f..54babc2b4b9ee 100644
--- a/drivers/clk/sunxi/clk-sun6i-ar100.c
+++ b/drivers/clk/sunxi/clk-sun6i-ar100.c
@@ -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
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!

-- 
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
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help