All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yang Yingliang <yangyingliang@huawei.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v6 3/3] arm: fix a migrating irq bug when hotplug cpu
Date: Tue, 15 Dec 2015 06:59:45 +0000	[thread overview]
Message-ID: <566FBA61.3010400@huawei.com> (raw)
In-Reply-To: <20151022111307.GS32532@n2100.arm.linux.org.uk>

Hi, Russell

On 2015/10/22 19:13, Russell King - ARM Linux wrote:
> 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.
>

The regression had been fixed.
Do I need to put the patch in the patch system again ?

Regards,
Yang


WARNING: multiple messages have this Message-ID (diff)
From: yangyingliang@huawei.com (Yang Yingliang)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v6 3/3] arm: fix a migrating irq bug when hotplug cpu
Date: Tue, 15 Dec 2015 14:59:45 +0800	[thread overview]
Message-ID: <566FBA61.3010400@huawei.com> (raw)
In-Reply-To: <20151022111307.GS32532@n2100.arm.linux.org.uk>

Hi, Russell

On 2015/10/22 19:13, Russell King - ARM Linux wrote:
> 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.
>

The regression had been fixed.
Do I need to put the patch in the patch system again ?

Regards,
Yang

WARNING: multiple messages have this Message-ID (diff)
From: Yang Yingliang <yangyingliang@huawei.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mark Rutland <mark.rutland@arm.com>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Hanjun Guo <hanjun.guo@linaro.org>,
	Jiang Liu <jiang.liu@linux.intel.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v6 3/3] arm: fix a migrating irq bug when hotplug cpu
Date: Tue, 15 Dec 2015 14:59:45 +0800	[thread overview]
Message-ID: <566FBA61.3010400@huawei.com> (raw)
In-Reply-To: <20151022111307.GS32532@n2100.arm.linux.org.uk>

Hi, Russell

On 2015/10/22 19:13, Russell King - ARM Linux wrote:
> 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.
>

The regression had been fixed.
Do I need to put the patch in the patch system again ?

Regards,
Yang


  parent reply	other threads:[~2015-12-15  6:59 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-24  9:32 [RFC PATCH v6 0/3] arm/arm64: fix a migrating irq bug when hotplug cpu Yang Yingliang
2015-09-24  9:32 ` Yang Yingliang
2015-09-24  9:32 ` [RFC PATCH v6 1/3] genirq: introduce CONFIG_GENERIC_IRQ_MIGRATION and kernel/irq/cpuhotplug.c Yang Yingliang
2015-09-24  9:32   ` Yang Yingliang
2015-10-01 14:18   ` [tip:irq/core] genirq: Introduce generic irq migration for cpu hotunplug tip-bot for Yang Yingliang
2015-10-01 14:24     ` Thomas Gleixner
2015-10-01 14:24       ` Thomas Gleixner
2015-10-01 14:47       ` Catalin Marinas
2015-10-01 14:47         ` Catalin Marinas
2015-09-24  9:32 ` [RFC PATCH v6 2/3] arm64: fix a migrating irq bug when hotplug cpu Yang Yingliang
2015-09-24  9:32   ` Yang Yingliang
2015-10-09 16:55   ` Catalin Marinas
2015-10-09 16:55     ` Catalin Marinas
2015-09-24  9:32 ` [RFC PATCH v6 3/3] arm: " Yang Yingliang
2015-09-24  9:32   ` Yang Yingliang
2015-10-13 19:28   ` Russell King - ARM Linux
2015-10-13 19:28     ` Russell King - ARM Linux
2015-10-21 11:47   ` Geert Uytterhoeven
2015-10-21 11:47     ` Geert Uytterhoeven
2015-10-21 11:47     ` Geert Uytterhoeven
2015-10-21 20:29     ` Russell King - ARM Linux
2015-10-21 20:29       ` Russell King - ARM Linux
2015-10-21 20:29       ` Russell King - ARM Linux
2015-10-22  9:26       ` Russell King - ARM Linux
2015-10-22  9:26         ` Russell King - ARM Linux
2015-10-22  9:26         ` Russell King - ARM Linux
2015-10-22  9:46         ` Geert Uytterhoeven
2015-10-22  9:46           ` Geert Uytterhoeven
2015-10-22  9:46           ` Geert Uytterhoeven
2015-10-22 10:56         ` Yang Yingliang
2015-10-22 10:56           ` Yang Yingliang
2015-10-22 10:56           ` Yang Yingliang
2015-10-22 11:13           ` Russell King - ARM Linux
2015-10-22 11:13             ` Russell King - ARM Linux
2015-10-22 11:13             ` Russell King - ARM Linux
2015-10-22 12:43             ` Thomas Gleixner
2015-10-22 12:43               ` Thomas Gleixner
2015-10-22 12:43               ` Thomas Gleixner
2015-10-22 16:34               ` Catalin Marinas
2015-10-22 16:34                 ` Catalin Marinas
2015-10-22 16:34                 ` Catalin Marinas
2015-12-15  6:59             ` Yang Yingliang [this message]
2015-12-15  6:59               ` Yang Yingliang
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=566FBA61.3010400@huawei.com \
    --to=yangyingliang@huawei.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.