From: Barry Song <21cnbao@gmail.com>
To: Meiyong Yu <meiyong.yu@126.com>
Cc: corbet@lwn.net, workflows@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Barry Song <v-songbaohua@oppo.com>,
Andrew Morton <akpm@linux-foundation.org>,
Chris Zankel <chris@zankel.net>,
Huacai Chen <chenhuacai@loongson.cn>,
Herbert Xu <herbert@gondor.apana.org.au>,
Guenter Roeck <linux@roeck-us.net>,
Max Filippov <jcmvbkbc@gmail.com>
Subject: Re: [PATCH] Documentation: coding-style: ask function-like macros to evaluate parameters
Date: Thu, 21 Mar 2024 13:11:11 +1300 [thread overview]
Message-ID: <CAGsJ_4xJsqOO-NXs3OWVA47vcK-zUpcrMxCbnY7x5khRH0dnxA@mail.gmail.com> (raw)
In-Reply-To: <EFB48F08-F0B5-47C0-8C47-00A542344AC9@126.com>
On Thu, Mar 21, 2024 at 12:39 PM Meiyong Yu <meiyong.yu@126.com> wrote:
>
>
> > On Mar 20, 2024, at 08:17, Barry Song <21cnbao@gmail.com> wrote:
> >
> > From: Barry Song <v-songbaohua@oppo.com>
> >
> > Recent commit 77292bb8ca69c80 ("crypto: scomp - remove memcpy if
> > sg_nents is 1 and pages are lowmem") leads to warnings on xtensa
> > and loongarch,
> > In file included from crypto/scompress.c:12:
> > include/crypto/scatterwalk.h: In function 'scatterwalk_pagedone':
> > include/crypto/scatterwalk.h:76:30: warning: variable 'page' set but not used [-Wunused-but-set-variable]
> > 76 | struct page *page;
> > | ^~~~
> > crypto/scompress.c: In function 'scomp_acomp_comp_decomp':
> >>> crypto/scompress.c:174:38: warning: unused variable 'dst_page' [-Wunused-variable]
> > 174 | struct page *dst_page = sg_page(req->dst);
> > |
> >
> > The reason is that flush_dcache_page() is implemented as a noop
> > macro on these platforms as below,
> >
> > #define flush_dcache_page(page) do { } while (0)
> >
> > The driver code, for itself, seems be quite innocent and placing
> > maybe_unused seems pointless,
> >
> > struct page *dst_page = sg_page(req->dst);
> >
> > for (i = 0; i < nr_pages; i++)
> > flush_dcache_page(dst_page + i);
> >
> > And it should be independent of architectural implementation
> > differences.
> >
> > Let's have a guidance in codingstyle to ask for the evaluation
> > of parameters.
> >
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Chris Zankel <chris@zankel.net>
> > Cc: Huacai Chen <chenhuacai@loongson.cn>
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: Guenter Roeck <linux@roeck-us.net>
> > Suggested-by: Max Filippov <jcmvbkbc@gmail.com>
> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> > ---
> > Documentation/process/coding-style.rst | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> > index 9c7cf7347394..8065747fddff 100644
> > --- a/Documentation/process/coding-style.rst
> > +++ b/Documentation/process/coding-style.rst
> > @@ -827,6 +827,13 @@ Macros with multiple statements should be enclosed in a do - while block:
> > do_this(b, c); \
> > } while (0)
> >
>
>
> > +Function-like macros should evaluate their parameters, for unused parameters,
> I do not support this point, if the parameter is unused, why not to remove it.
>
Linux boasts support for numerous architectures, striving for
independence in its
drivers and core code implementation across these architectures. Consequently,
certain architectures may utilize parameters for the same APIs, while others may
not.
> about the warning, is tool misreport, the tool must make better
>
no. This is not the case.
> > +cast them to void:
> > +
> > +.. code-block:: c
> > +
> > + #define macrofun(a) do { (void) (a); } while (0)
> > +
> > Things to avoid when using macros:
> >
> > 1) macros that affect control flow:
> > --
> > 2.34.1
> >
>
>
next prev parent reply other threads:[~2024-03-21 0:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-20 0:16 Barry Song
2024-03-20 1:42 ` Stephen Rothwell
2024-03-20 3:24 ` Barry Song
2024-03-20 3:45 ` Stephen Rothwell
2024-03-20 15:49 ` Andrew Morton
2024-03-20 18:48 ` Barry Song
2024-03-21 11:15 ` Mark Brown
2024-03-21 20:29 ` Barry Song
2024-03-21 17:44 ` Andrew Morton
2024-03-20 23:37 ` Meiyong Yu
2024-03-21 0:11 ` Barry Song [this message]
2024-03-21 4:38 ` Meiyong Yu
2024-03-21 7:42 ` Barry Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGsJ_4xJsqOO-NXs3OWVA47vcK-zUpcrMxCbnY7x5khRH0dnxA@mail.gmail.com \
--to=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chenhuacai@loongson.cn \
--cc=chris@zankel.net \
--cc=corbet@lwn.net \
--cc=herbert@gondor.apana.org.au \
--cc=jcmvbkbc@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=meiyong.yu@126.com \
--cc=v-songbaohua@oppo.com \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox