Re: [GIT pull] irq updates for 4.13

[Tony Lindgren <tony@atomide.com>]

* Pavel Machek <pavel@ucw.cz> [170715 13:24]:
> Hi!
> 
> > > On Tue, Jul 11, 2017 at 11:41:52PM +0200, Thomas Gleixner wrote:
> > > > [...]
> > > >
> > > > Here is a revised version of the previous patch with the conditional
> > > > locking removed and a bunch of comments added.
> > > 
> > > That one also fixes Droid 4 boot.
> > > 
> > > Tested-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> > 
> > Sill works for me too:
> > 
> > Tested-by: Tony Lindgren <tony@atomide.com>
> 
> I seen the announcement
> 
> Date: Wed, 12 Jul 2017 01:18:50 -0700
> From: tip-bot for Thomas Gleixner <tipbot@zytor.com>
> To: linux-tip-commits@vger.kernel.org
> Subject: [tip:irq/urgent] genirq: Keep chip buslock across
> irq_request/release_resources()
> 
> But I don't see the commit in 4.13-rc0. Could we get it in now, so
> that problem is fixed in -rc1?

Seems we missed that for -rc1. In general, I've noticed that the rule
of having code sit in next before the merge window really helps
preventing regressions during the merge window. That is as long
people keep testing next on almost daily basis and report
regressions promptly.. and I do just to avoid chasing regressions
during the -rc cycle.

And the real reason why I think catching the regressions in next
helps is the fact that people react to regressions much faster to
revert patches compared to after things get merged into the mainline
kernel :p

In this case Thomas reacted within hours and fixed the issue, so
no issues there and thanks for doing that. But we still got -rc1
with a regression that probably could have been prevented with
enough time in next. So maybe we should be more strict with the
next requirement? Just sayin.

Tony