On Sat, Feb 17, 2018 at 07:12:17AM -0800, Guenter Roeck wrote:

On 02/17/2018 05:43 AM, Greg Kroah-Hartman wrote:

quoted

On Fri, Feb 16, 2018 at 10:52:20AM -0800, Guenter Roeck wrote:

quoted

On Fri, Feb 16, 2018 at 10:10:44AM -0800, Brian Norris wrote:

quoted

On Fri, Feb 16, 2018 at 07:48:50AM +0100, Greg Kroah-Hartman wrote:

quoted

On Thu, Feb 15, 2018 at 06:31:48PM -0800, Brian Norris wrote:

quoted

On Thu, Feb 15, 2018 at 04:17:32PM +0100, Greg Kroah-Hartman wrote:

quoted

4.4-stable review patch.  If anyone has any objections, please let me know.

Consider this an objection:

I'm currently arguing that this is unnecessarily regressing power
consumption here:

https://patchwork.kernel.org/patch/10149195/

I'll leave it up to you what to do with this, but if this ends up in
Chromium OS kernels, I'm likely to revert it there...

Is that patch in Linus's tree yet?  If so, I'll be glad to also apply it
here.

The link is the original patch, where I'm (too late?) complaining about
its side effects. Hans and Marcel are discussing potential alternatives.
This stuff happens in -rc kernels. But you're already ready to push it
out to -stable users? I can try to push another few reverts into Linus's
tree if that really helps, or else you can wait on pushing these to
-stable until 4.16 settles down.

FWIW, here are the various commit SHAs.

Upstream:			61f5acea8737
v4.15 (queued for v4.15.4):	e766a2d7f7c2
v4.14 (queued for v4.14.20):	736385472dfa
v4.9 (queued for v4.9.82):	1c6fc2167678
v4.4 (queued for v4.4.116):	575538a5371d

I didn't check older stable kernels.

Thanks, but I've now released all of these with this patch committed, so
we are now "bug compatible" :)

FWIW, seems to me that trying to be "bug compatible" with -rc1 upstream
kernels may not really be a good idea for stable releases.

It's a tough trade-off.  If I dropped this patch, the normal mode of
operation would be for it to get merged into device kernels and then
forgotten about.  Only if/when the user with the problem moves to a
newer release a long time later would the regression normally appear
again, and everyone would have to remember what happened and try to
piece it all together again as to what commit caused the issue.

By you adding the revert to your device kernel now, you have a record of
this being a problem, how upstream isn't fixing the issue, and when/if
you do move to a newer kernel, that bugfix will still be there in your
patch stack to forward port.

Yeah, you all are normally better than that, and I trust that you will
push to get this resolved, hopefully soon.  But for the most part, this
method works best overall for the majority of the cases like this as not
all bug reporters are persistent, and if not, the maintainer usually
forgets about it as no one is saying anything and they have other things
to work on.

Well, bluetooth is known to not have responsive maintainers, so who am I
kidding here, odds are it's only going to get fixed as Hans is
involved, despite the bluetooth maintainers :)

thanks,

greg k-h