From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f68.google.com ([209.85.215.68]:43188 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752175AbdLMOF7 (ORCPT ); Wed, 13 Dec 2017 09:05:59 -0500 Date: Wed, 13 Dec 2017 15:05:59 +0100 From: Johan Hovold To: alexander.levin@verizon.com Cc: Johan Hovold , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" , Marcel Holtmann Subject: Re: [PATCH AUTOSEL for 4.14 19/60] Bluetooth: avoid silent hci_bcm ACPI PM regression Message-ID: <20171213140559.GE5185@localhost> References: <20171213015455.6455-1-alexander.levin@verizon.com> <20171213015455.6455-19-alexander.levin@verizon.com> <20171213081429.GC5185@localhost> <20171213133716.hfdujad4so652ll2@sasha-lappy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171213133716.hfdujad4so652ll2@sasha-lappy> Sender: stable-owner@vger.kernel.org List-ID: On Wed, Dec 13, 2017 at 01:37:26PM +0000, alexander.levin@verizon.com wrote: > On Wed, Dec 13, 2017 at 09:14:29AM +0100, Johan Hovold wrote: > >On Wed, Dec 13, 2017 at 01:55:14AM +0000, alexander.levin@verizon.com wrote: > >> From: Johan Hovold > >> > >> [ Upstream commit 4294625e029028854596865be401b9c5c1f906ef ] > >> > >> The hci_bcm platform-device hack which was used to implement > >> power management for ACPI devices is being replaced by a > >> serial-device-bus implementation. > >> > >> Unfortunately, when the corresponding change to the ACPI code lands (a > >> change that will stop enumerating and registering the serial-device-node > >> child as a platform device) PM will break silently unless serdev > >> TTY-port controller support has been enabled. Specifically, hciattach > >> (btattach) would still succeed, but power management would no longer > >> work. > > > >This one is not needed in stable, which does not have the above > >mentioned ACPI change [ e361d1f85855 ("ACPI / scan: Fix enumeration for > >special UART devices") ]. > > > >The Fixes and stable-CC tags were left out on purpose. > > Thanks Johan, I'll remove it. > > The Fixes tag should probably be there, as on it's own it does not > indicate a patch should go into stable, and we have tools to prevent > us from applying commits that "Fixes:" something which is not in the > tree. But that's the point; this patch was applied before the patch which might otherwise have ended up causing a regression. There was no commit id to use for a Fixes tag, and it did not fix anything when it was applied; its purpose was to avoid future breakage. Johan