linux-m68k.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

-- 

  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).