SUPERH platform development
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v6 3/3] arm: fix a migrating irq bug when hotplug cpu
Date: Thu, 22 Oct 2015 11:13:07 +0000	[thread overview]
Message-ID: <20151022111307.GS32532@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <5628C0DD.50900@huawei.com>

On Thu, Oct 22, 2015 at 06:56:29PM +0800, Yang Yingliang wrote:
> I described it in v2 cover letter and kept the change history in v6
> cover letter. There is no comment on the change when patch the was
> reviewing in v2, so I thought it's ok and I kept the change in the
> next versions.

Cover letters don't always get read, neither do changelogs.

However, there's a principle here: never mix moving code around with
changes to that code.  Always move code with as few changes as possible
in one patch, and then make changes in a subsequent patch.

The "few changes as possible" means that if you need to make changes
for it to end up building in its new location, such as removing a
'static' or adding an 'EXPORT_SYMBOL' then those are fine, but the
main body of the code should remain identical, even down to style.

Any changes (such as, in this case, replacing pr_debug with pr_warn)
should be done as a distinctly separate patch so that such changes
are immediately obvious to reviewers.

> Need I send a patch to the Thomas branch to revert the change ?

I think wait for Thomas and Catalin to reply.  Your patch series is
currently merged into two different trees (Thomas' and Catalin's
trees) and what action is needed depends on how they want to handle
it.

The solutions are:
* A patch to restore the pr_debug() which Thomas applies, and Catalin
  and myself then pull Thomas' tree again, which potentially creates
  a messier history.

* Catalin drops the ARM64 change and Thomas' tree from the ARM64 tree,
  Thomas drops the original commit, and we start again doing it
  correctly.

Which is up to Catalin and Thomas.

I've dropped it from my tree as an easy way to fix the regression
on ARM for the time being, pending the outcome of deciding how to
fix this.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2015-10-22 11:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1443087135-17044-1-git-send-email-yangyingliang@huawei.com>
     [not found] ` <1443087135-17044-4-git-send-email-yangyingliang@huawei.com>
2015-10-21 11:47   ` [RFC PATCH v6 3/3] arm: fix a migrating irq bug when hotplug cpu Geert Uytterhoeven
2015-10-21 20:29     ` Russell King - ARM Linux
2015-10-22  9:26       ` Russell King - ARM Linux
2015-10-22  9:46         ` Geert Uytterhoeven
2015-10-22 10:56         ` Yang Yingliang
2015-10-22 11:13           ` Russell King - ARM Linux [this message]
2015-10-22 12:43             ` Thomas Gleixner
2015-10-22 16:34               ` Catalin Marinas
2015-12-15  6:59             ` Yang Yingliang

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=20151022111307.GS32532@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.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