public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: "Johan Hovold" <johan+linaro@kernel.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Andy Gross" <agross@kernel.org>,
	"Bjorn Andersson" <andersson@kernel.org>,
	"Konrad Dybcio" <konrad.dybcio@linaro.org>,
	"Rob Herring" <robh@kernel.org>,
	"Nirmal Patel" <nirmal.patel@linux.intel.com>,
	"Jonathan Derrick" <jonathan.derrick@linux.dev>,
	linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/6] PCI: qcom: Clean up ASPM comment
Date: Fri, 17 Nov 2023 15:03:24 +0100	[thread overview]
Message-ID: <ZVdyrGXyahM7bxwh@hovoldconsulting.com> (raw)
In-Reply-To: <20231117112352.GS250770@thinkpad>

On Fri, Nov 17, 2023 at 04:53:52PM +0530, Manivannan Sadhasivam wrote:
> On Fri, Nov 17, 2023 at 12:00:44PM +0100, Johan Hovold wrote:
> > On Fri, Nov 17, 2023 at 04:24:04PM +0530, Manivannan Sadhasivam wrote:
> > > On Fri, Nov 17, 2023 at 11:48:10AM +0100, Johan Hovold wrote:

> > > > The coding style clearly states:
> > > > 
> > > > 	The preferred limit on the length of a single line is 80 columns.
> > > > 
> > > > 	Statements longer than 80 columns should be broken into sensible chunks,
> > > > 	unless exceeding 80 columns significantly increases readability and does
> > > > 	not hide information.
> > > > 
> > > > Going beyond 80 chars may sometimes be warranted for code, but the
> > > > exception is not intended for comments.
> > > 
> > > Breaking the comment here is indeed making it hard to read. It's just one word
> > > that needs to be broken if we go by 80 column limit and I won't prefer that,
> > > sorry!
> > 
> > Please read the above quote again, it is as clear as it gets. 80 chars
> > is the preferred limit unless (for code) exceeding it *significantly*
> 
> Where does it say "code" in the Documentation? As I read it, the doc weighs both
> code and comment as "statement".

No, comments are not statements (in C).

You'd also never even consider interpreting it that way if you knew
where that exception comes from (namely that people break long
*statements* just to fit under 80 chars, thereby sometimes making the
*code* unnecessarily hard to read).

> And how on the world that breaking a single word to the next line improves
> readability? I fail to get it :/

You got it backwards; you should only go *beyond* 80 chars if it
"significantly increases readability".

But again, this does NOT apply to comments in the first place.

> > increases readability, which clearly isn't the case here (even if this
> > exception applied to comments).
> > 
> > I really don't understand why you keep insisting on this. Just fix your
> > editor.

> But I do not want to get into a spat here. Checkpatch, the tool supposed to
> check for the kernel coding style is not complaining and I do not want a patch
> that _fixes_ a coding style that is not an issue.

Checkpatch is just a tool, not the standard, and knowing when it is ok
to break the 80 column rule for code requires human judgement.

Johan

  reply	other threads:[~2023-11-17 14:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-14 13:55 [PATCH 0/6] PCI: Fix deadlocks when enabling ASPM Johan Hovold
2023-11-14 13:55 ` [PATCH 1/6] PCI/ASPM: Add locked helper for enabling link state Johan Hovold
2023-11-15 14:26   ` kernel test robot
2023-11-15 16:06     ` Johan Hovold
2023-11-17 10:27       ` Manivannan Sadhasivam
2023-11-17 10:30         ` Johan Hovold
2023-11-17 10:50           ` Manivannan Sadhasivam
2023-11-17 10:28   ` Manivannan Sadhasivam
2023-11-18  0:00   ` David E. Box
2023-11-20  8:33     ` Johan Hovold
2023-11-14 13:55 ` [PATCH 2/6] PCI: vmd: Fix deadlock when enabling ASPM Johan Hovold
2023-11-17 10:28   ` Manivannan Sadhasivam
2023-11-14 13:55 ` [PATCH 3/6] PCI: qcom: " Johan Hovold
2023-11-17 10:28   ` Manivannan Sadhasivam
2023-11-14 13:55 ` [PATCH 4/6] PCI: qcom: Clean up ASPM comment Johan Hovold
2023-11-17 10:32   ` Manivannan Sadhasivam
2023-11-17 10:48     ` Johan Hovold
2023-11-17 10:54       ` Manivannan Sadhasivam
2023-11-17 11:00         ` Johan Hovold
2023-11-17 11:23           ` Manivannan Sadhasivam
2023-11-17 14:03             ` Johan Hovold [this message]
2023-11-14 13:55 ` [PATCH 5/6] PCI/ASPM: Clean up disable link state parameter Johan Hovold
2023-11-17 10:35   ` Manivannan Sadhasivam
2023-11-14 13:55 ` [PATCH 6/6] PCI/ASPM: Add lockdep assert to link state helper Johan Hovold
2023-11-17 10:36   ` Manivannan Sadhasivam

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=ZVdyrGXyahM7bxwh@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=johan+linaro@kernel.org \
    --cc=jonathan.derrick@linux.dev \
    --cc=konrad.dybcio@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=nirmal.patel@linux.intel.com \
    --cc=robh@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