From: Dan Carpenter <dan.carpenter@oracle.com>
To: Philipp Hortmann <philipp.g.hortmann@gmail.com>
Cc: Forest Bond <forest@alittletooquiet.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 04/12] staging: vt6655: Cleanup and rename function MACbSafeSoftwareReset
Date: Tue, 13 Sep 2022 13:12:55 +0300 [thread overview]
Message-ID: <YyBXp9x1LnBkku2g@kadam> (raw)
In-Reply-To: <540a684266610f7618b3ef6000d4699d065c8e6f.1662890990.git.philipp.g.hortmann@gmail.com>
On Sun, Sep 11, 2022 at 12:46:04PM +0200, Philipp Hortmann wrote:
> Rename function MACbSafeSoftwareReset to vt6655_mac_save_soft_reset and
> abyTmpRegData to tmp_reg_data to avoid CamelCase which is not accepted by
> checkpatch.pl. Remove return value bRetVal as it is unused by the calling
> functions.
Please don't mix this kind of stuff into a patch like this.
> Remove unnecessary declaration of function and make function
> static. Change declaration of tmp_reg_data to shorten code.
When I'm reviewing rename patches I have a script where I call
`rename_rev.pl -a` and it just parses the patch and outputs:
RENAMES:
abyTmpRegData => tmp_reg_data
MACbSafeSoftwareReset => vt6655_mac_save_soft_reset
I don't invest much time in thinking about the new names. The review
takes me about 5 seconds.
Then once you start marking the functions as static then that's slightly
a headache because now I have to look at that part by hand. But
whatever, you can kind of sell that as one thing.
But then when you mix ignoring the error codes in as well it's a big
headache. At first I thought it was because MACbSoftwareReset() always
returns true, so I pulled up that code and that's not true. So then I
am annoyed. And I pull up the commit message to see what's going on
and sure enough that change is burried in the middle of the paragraph.
Don't do that. Just do the renames. Then change all the functions in
one file to static at once. Then make the function void in a separate
patch.
The other thing is that making functions static is not at all
controversial. So long as it builds we will always accept those
patches.
Renaming variables is not super controversial. Sometimes people quarrel
about the new name. For example, I don't like a tmp variable which has
a long name like "tmp_reg_data". Just call it either "tmp" or
"reg_data". Not both. Don't write an essay.
But making functions void is sort of controversial... It's probably the
right thing in this context. But what I'm saying is don't mix things
which different controversial levels, because it means that someone is
going to complain. I would have ignored the "tmp_reg_data" thing
except now I'm already complaining about stuff I may as well mention it.
regards,
dan carpenter
next prev parent reply other threads:[~2022-09-13 10:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-11 10:45 [PATCH 00/12] staging: vt6655: Cleanup and rename functions of mac.h Philipp Hortmann
2022-09-11 10:45 ` [PATCH 01/12] staging: vt6655: Cleanup and rename function MACvSetLoopbackMode Philipp Hortmann
2022-09-11 10:45 ` [PATCH 02/12] staging: vt6655: Cleanup and rename function MACvSaveContext Philipp Hortmann
2022-09-11 10:45 ` [PATCH 03/12] staging: vt6655: Cleanup and rename function MACvRestoreContext Philipp Hortmann
2022-09-11 10:46 ` [PATCH 04/12] staging: vt6655: Cleanup and rename function MACbSafeSoftwareReset Philipp Hortmann
2022-09-13 10:12 ` Dan Carpenter [this message]
2022-09-13 18:26 ` Philipp Hortmann
2022-09-14 14:47 ` Dan Carpenter
2022-09-11 10:46 ` [PATCH 05/12] staging: vt6655: Rename function MACbSafeRxOff Philipp Hortmann
2022-09-11 10:46 ` [PATCH 06/12] staging: vt6655: Rename function MACbSafeTxOff Philipp Hortmann
2022-09-11 10:46 ` [PATCH 07/12] staging: vt6655: Rename function MACbSafeStop Philipp Hortmann
2022-09-11 10:46 ` [PATCH 08/12] staging: vt6655: Rename function MACvSetCurrRx0DescAddr Philipp Hortmann
2022-09-11 10:47 ` [PATCH 09/12] staging: vt6655: Rename function MACvSetCurrRx1DescAddr Philipp Hortmann
2022-09-11 10:47 ` [PATCH 10/12] staging: vt6655: Cleanup and rename function MACvSetCurrTXDescAddr Philipp Hortmann
2022-09-11 10:47 ` [PATCH 11/12] staging: vt6655: Rename function MACvSetCurrTx0DescAddrEx Philipp Hortmann
2022-09-11 10:47 ` [PATCH 12/12] staging: vt6655: Rename function MACvSetCurrAC0DescAddrEx Philipp Hortmann
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=YyBXp9x1LnBkku2g@kadam \
--to=dan.carpenter@oracle.com \
--cc=forest@alittletooquiet.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=philipp.g.hortmann@gmail.com \
/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