[PATCH 1/3] scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none

[PATCH 1/3] scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none

[Will Deacon]

My bisect scripts starting running into build failures when trying to
compile 4.15-rc1 with the builds failing with things like:

drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union!

The line in question is actually just a #define, but after some digging
it turns out that my scripts pass W=1 and since commit 3a025e1d1c2ea
("Add optional check for bad kernel-doc comments") that results in
kernel-doc running on each source file. The file in question has a
badly formatted comment immediately before the #define:

/**
 * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
 * bus layer usage.
 */

which causes the regex in dump_struct to fail (lack of braces following
struct declaration) and kernel-doc returns 1, which causes the build
to fail.

Fix the issue by always returning 0 from kernel-doc when invoked with
-none. It successfully generates no documentation, and prints out any
issues.

Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 scripts/kernel-doc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index bd29a92b4b48..df0f045a9a89 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -3248,4 +3248,4 @@ if ($verbose && $warnings) {
   print STDERR "$warnings warnings\n";
 }
 
-exit($errors);
+exit($output_mode eq "none" ? 0 : $errors);
-- 
2.1.4

[PATCH 2/3] brcmfmac: Fix comment syntax

[Will Deacon]

"/**" identifies a kerneldoc comment, so avoid using it for comments that
don't conform to kerneldoc syntax. Without this patch, kerneldoc throws
errors when building the kernel with W=1.

Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
Cc: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 310c4e2746aa..604afff4b6a1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -2070,7 +2070,7 @@ static int brcmf_sdio_txpkt_hdalign(struct brcmf_sdio *bus, struct sk_buff *pkt)
 	return head_pad;
 }
 
-/**
+/*
  * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
  * bus layer usage.
  */
-- 
2.1.4

[PATCH 3/3] drm/ttm: Fix comment syntax

[Will Deacon]

"/**" identifies a kerneldoc comment, so avoid using it for comments that
don't conform to kerneldoc syntax. Without this patch, kerneldoc throws
errors when building the kernel with W=1.

Cc: David Airlie <airlied@linux.ie>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 drivers/gpu/drm/ttm/ttm_object.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index 26a7ad0f4789..0f5800c1a57d 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -41,7 +41,7 @@
  */
 
 
-/**
+/*
  * struct ttm_object_file
  *
  * @tdev: Pointer to the ttm_object_device.
-- 
2.1.4

Re: [PATCH 1/3] scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none

[Jonathan Corbet]

On Wed, 29 Nov 2017 15:20:03 +0000
Will Deacon <will.deacon@arm.com> wrote:

> My bisect scripts starting running into build failures when trying to
> compile 4.15-rc1 with the builds failing with things like:
> 
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union!
> 
> The line in question is actually just a #define, but after some digging
> it turns out that my scripts pass W=1 and since commit 3a025e1d1c2ea
> ("Add optional check for bad kernel-doc comments") that results in
> kernel-doc running on each source file. The file in question has a
> badly formatted comment immediately before the #define:
> 
> /**
>  * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
>  * bus layer usage.
>  */
> 
> which causes the regex in dump_struct to fail (lack of braces following
> struct declaration) and kernel-doc returns 1, which causes the build
> to fail.
> 
> Fix the issue by always returning 0 from kernel-doc when invoked with
> -none. It successfully generates no documentation, and prints out any
> issues.

That seems like a worthy fix.  I can take this one and ship it up with a
few other docs fixes in the near future, thanks.

jon

Re: [PATCH 1/3] scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none

[Will Deacon]

On Wed, Nov 29, 2017 at 09:12:14AM -0700, Jonathan Corbet wrote:
> On Wed, 29 Nov 2017 15:20:03 +0000
> Will Deacon <will.deacon@arm.com> wrote:
> 
> > My bisect scripts starting running into build failures when trying to
> > compile 4.15-rc1 with the builds failing with things like:
> > 
> > drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union!
> > 
> > The line in question is actually just a #define, but after some digging
> > it turns out that my scripts pass W=1 and since commit 3a025e1d1c2ea
> > ("Add optional check for bad kernel-doc comments") that results in
> > kernel-doc running on each source file. The file in question has a
> > badly formatted comment immediately before the #define:
> > 
> > /**
> >  * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
> >  * bus layer usage.
> >  */
> > 
> > which causes the regex in dump_struct to fail (lack of braces following
> > struct declaration) and kernel-doc returns 1, which causes the build
> > to fail.
> > 
> > Fix the issue by always returning 0 from kernel-doc when invoked with
> > -none. It successfully generates no documentation, and prints out any
> > issues.
> 
> That seems like a worthy fix.  I can take this one and ship it up with a
> few other docs fixes in the near future, thanks.

Brill, cheers Jon. It had me extremely confused for a while until I figured
out the warning wasn't coming from GCC :)

Will