From: Finn Thain <fthain@telegraphics.com.au>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux/m68k <linux-m68k@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 00/14] Modernization and fixes for NuBus subsystem
Date: Sat, 6 Jan 2018 14:34:56 +1100 (AEDT) [thread overview]
Message-ID: <alpine.LNX.2.21.1801060823160.3@nippy.intranet> (raw)
In-Reply-To: <CAMuHMdX1Z0y2u1nkj3GqF5N3jYBYvfjM9_jJKH0zM23DBNjhOw@mail.gmail.com>
Hi Geert,
On Fri, 5 Jan 2018, Geert Uytterhoeven wrote:
>
> I assume you meant this to go in through the m68k tree?
>
Yes, please. Because the NuBus-PowerMac port is out-of-tree, the m68k tree
seems more appropriate than the powerpc tree for this submission.
> Can you please run this through checkpatch, and fix the reported white
> space and other real (some are false positives) issues?
>
Checkpatch is great but it is also incredibly noisy. So I missed a long
line that should have been wrapped in patch 4/14 and another in 5/14.
Sorry about that.
Checkpatch said, "Symbolic permissions are not preferred". But I didn't
find any advice in the style guide, so I just retained the existing code
style. What is your preference here?
Checkpatch also said, "code indent should use tabs where possible" though
I've used only tabs to indent (according to scope, of course). Checkpatch
also says, "please, no spaces at the start of a line". Yet it is common
practice to put spaces at the start of a continuation (after any
indentation tabs, of course) when wrapping lines*. Please let me know your
preference.
Checkpatch asked, "added, moved or deleted file(s), does MAINTAINERS need
updating?" Regarding drivers/nubus/*, that question is not a new one. The
issue can be addressed in this patch or an earlier one, so as to keep
checkpatch happy, or it can be addressed in a separate submission... Do we
bring drivers/nubus/* under the Mac 68k subsystem? Isn't it a subsystem
itself? (If maintain that code, do I get to exercise my discretion
regarding checkpatch limitations?)
The rest of the checkpatch output seems to be irrelevant (or am I missing
something?) --
Macros with complex values should be enclosed in parentheses
trailing statements should be on next line
Possible unwrapped commit description
braces {} are not necessary for single statement blocks
file is marked as 'obsolete' in the MAINTAINERS hierarchy. No
unnecessary modifications please.
suspect code indent for conditional statements
Please let me know how you would like me to address these issues, and I'll
re-submit.
Thanks for your review.
* IMO checkpatch is really good at certain things but line wrap isn't one
of them. The git project's Documentation/CodingGuidelines seems to be a
better description of Linux development practice than checkpatch's regexps:
There are two schools of thought when it comes to splitting a long
logical line into multiple lines. Some people push the second and
subsequent lines far enough to the right with tabs and align them:
if (the_beginning_of_a_very_long_expression_that_has_to ||
span_more_than_a_single_line_of ||
the_source_text) {
...
while other people prefer to align the second and the subsequent
lines with the column immediately inside the opening parenthesis,
with tabs and spaces, following our "tabstop is always a multiple
of 8" convention:
if (the_beginning_of_a_very_long_expression_that_has_to ||
span_more_than_a_single_line_of ||
the_source_text) {
...
Both are valid, and we use both. Again, just do not mix styles in
the same part of the code and mimic existing styles in the
neighbourhood.
--
next prev parent reply other threads:[~2018-01-06 3:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-14 3:16 [PATCH v4 00/14] Modernization and fixes for NuBus subsystem Finn Thain
2017-12-14 3:16 ` [PATCH v4 06/14] nubus: Call proc_mkdir() not more than once per slot directory Finn Thain
2017-12-14 3:16 ` [PATCH v4 07/14] nubus: Remove redundant code Finn Thain
2017-12-14 3:16 ` [PATCH v4 10/14] nubus: Rework /proc/bus/nubus/s/ implementation Finn Thain
2017-12-14 3:16 ` [PATCH v4 11/14] nubus: Rename struct nubus_dev Finn Thain
2017-12-14 3:16 ` [PATCH v4 03/14] nubus: Use static functions where possible Finn Thain
2017-12-14 3:16 ` [PATCH v4 14/14] nubus: Add support for the driver model Finn Thain
2017-12-14 3:16 ` [PATCH v4 01/14] nubus: Avoid array underflow and overflow Finn Thain
2017-12-14 3:16 ` [PATCH v4 02/14] nubus: Fix up header split Finn Thain
2017-12-14 3:16 ` [PATCH v4 09/14] nubus: Generalize block resource handling Finn Thain
2017-12-14 3:16 ` [PATCH v4 08/14] nubus: Clean up whitespace Finn Thain
2017-12-14 3:16 ` [PATCH v4 04/14] nubus: Fix log spam Finn Thain
2017-12-14 3:16 ` [PATCH v4 13/14] nubus: Add expansion_type values for various Mac models Finn Thain
2017-12-14 3:16 ` [PATCH v4 05/14] nubus: Validate slot resource IDs Finn Thain
2017-12-14 3:16 ` [PATCH v4 12/14] nubus: Adopt standard linked list implementation Finn Thain
2018-01-05 13:20 ` [PATCH v4 00/14] Modernization and fixes for NuBus subsystem Geert Uytterhoeven
2018-01-06 3:34 ` Finn Thain [this message]
2018-01-07 10:14 ` Geert Uytterhoeven
2018-01-08 2:58 ` Finn Thain
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=alpine.LNX.2.21.1801060823160.3@nippy.intranet \
--to=fthain@telegraphics.com.au \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@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;
as well as URLs for NNTP newsgroup(s).