[v1,0/6] Fix device links functional breakage in 4.19.99

Message ID	20200317065452.236670-1-saravanak@google.com (mailing list archive)
Headers	show Return-Path: <SRS0=gput=5C=lists.infradead.org=linux-mediatek-bounces+patchwork-linux-mediatek=patchwork.kernel.org@kernel.org> DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 59E3F20674 Date: Mon, 16 Mar 2020 23:54:46 -0700 Message-Id: <20200317065452.236670-1-saravanak@google.com> Mime-Version: 1.0 Subject: [PATCH v1 0/6] Fix device links functional breakage in 4.19.99 From: Saravana Kannan <saravanak@google.com> To: stable@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>, Matthias Brugger <matthias.bgg@gmail.com> summary: Content analysis details: (-7.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:64a listed in] [list.dnswl.org] -7.5 USER_IN_DEF_DKIM_WL From: address is in the default DKIM white-list -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.0 DKIMWL_WL_MED DKIMwl.org - Medium sender Precedence: list Cc: Saravana Kannan <saravanak@google.com>, linux-pm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, kernel-team@android.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" <linux-mediatek-bounces@lists.infradead.org> Errors-To: linux-mediatek-bounces+patchwork-linux-mediatek=patchwork.kernel.org@lists.infradead.org
Series	Fix device links functional breakage in 4.19.99 \| expand [v1,0/6] Fix device links functional breakage in 4.19.99 [v1,1/6] driver core: Remove the link if there is no driver with AUTO flag [v1,2/6] driver core: Fix adding device links to probing suppliers [v1,3/6] driver core: Make driver core own stateful device links [v1,4/6] driver core: Add device link flag DL_FLAG_AUTOPROBE_CONSUMER [v1,5/6] driver core: Remove device link creation limitation [v1,6/6] driver core: Fix creation of device links with PM-runtime flags

Message ID

20200317065452.236670-1-saravanak@google.com (mailing list archive)

Headers

DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 59E3F20674
Date: Mon, 16 Mar 2020 23:54:46 -0700
Message-Id: <20200317065452.236670-1-saravanak@google.com>
Mime-Version: 1.0
Subject: [PATCH v1 0/6] Fix device links functional breakage in 4.19.99
From: Saravana Kannan <saravanak@google.com>
To: stable@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 "Rafael J. Wysocki" <rafael@kernel.org>,
 Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
 Matthias Brugger <matthias.bgg@gmail.com>
Precedence: list
Cc: Saravana Kannan <saravanak@google.com>, linux-pm@vger.kernel.org,
 linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
 linux-mediatek@lists.infradead.org, kernel-team@android.com,
 linux-arm-kernel@lists.infradead.org
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Linux-mediatek" <linux-mediatek-bounces@lists.infradead.org>
Errors-To: 
 linux-mediatek-bounces+patchwork-linux-mediatek=patchwork.kernel.org@lists.infradead.org

Series

Fix device links functional breakage in 4.19.99 | expand

Message

Saravana Kannan March 17, 2020, 6:54 a.m. UTC

As mentioned in an earlier email thread [1], 4.19.99 broke the ability
to create stateful and stateless device links between the same set of
devices when it pulled in a valid bug fix [2]. While the fix was valid,
it removes a functionality that was present before the bug fix.

This patch series attempts to fix that by pulling in more patches from
upstream. I've just done compilation testing so far. But wanted to send
out a v1 to see if this patch list was acceptable before I fixed up the
commit text format to match what's needed for stable mailing list.

Some of the patches are new functionality, but for a first pass, it was
easier to pull these in than try and fix the conflicts. If these patches
are okay to pull into stable, then all I need to do is fix the commit
text.

Thanks,
Saravana

[1] - https://lore.kernel.org/stable/CAGETcx-0dKRWo=tTVcfJQhQUsMtX_LtL6yvDkb3CMbvzREsvOQ@mail.gmail.com/#t
[2] - 6fdc440366f1a99f344b629ac92f350aefd77911


Rafael J. Wysocki (5):
  driver core: Fix adding device links to probing suppliers
  driver core: Make driver core own stateful device links
  driver core: Add device link flag DL_FLAG_AUTOPROBE_CONSUMER
  driver core: Remove device link creation limitation
  driver core: Fix creation of device links with PM-runtime flags

Yong Wu (1):
  driver core: Remove the link if there is no driver with AUTO flag

 Documentation/driver-api/device_link.rst |  63 +++--
 drivers/base/core.c                      | 293 +++++++++++++++++------
 drivers/base/dd.c                        |   2 +-
 drivers/base/power/runtime.c             |   4 +-
 include/linux/device.h                   |   7 +-
 5 files changed, 265 insertions(+), 104 deletions(-)

Comments

Saravana Kannan March 18, 2020, 7:10 p.m. UTC | #1

On Mon, Mar 16, 2020 at 11:54 PM Saravana Kannan <saravanak@google.com> wrote:
>
> As mentioned in an earlier email thread [1], 4.19.99 broke the ability
> to create stateful and stateless device links between the same set of
> devices when it pulled in a valid bug fix [2]. While the fix was valid,
> it removes a functionality that was present before the bug fix.
>
> This patch series attempts to fix that by pulling in more patches from
> upstream. I've just done compilation testing so far. But wanted to send
> out a v1 to see if this patch list was acceptable before I fixed up the
> commit text format to match what's needed for stable mailing list.
>
> Some of the patches are new functionality, but for a first pass, it was
> easier to pull these in than try and fix the conflicts. If these patches
> are okay to pull into stable, then all I need to do is fix the commit
> text.

I took a closer look at all the patches. Everyone of them is a bug fix
except Patch 4/6. But Patch 4/6 is a fairly minimal change and I think
it's easier/cleaner to just pick it up too instead of trying to
resolve merge conflicts in the stable branch.

1/6 - Fixes what appears to be a memory leak bug in upstream.
2/6 - Fixes error in initial state of the device link if it's created
under some circumstances.
3/6 - Fixes a ref count bug in upstream. Looks like it can lead to memory leaks?
4/6 - Adds a minor feature to kick off a probe attempt of a consumer
5/6 - Fixes the break in functionality that happened in 4.19.99
6/6 - Fixes bug in 5/6 (upstream bug)

Greg

Do these patches look okay for you to pull into 4.19 stable? If so,
please let me know if you need me to send v2 with commit fix up.

The only fix up needed is to these patches at this point is changing
"(cherry picked from commit ...)" with "[ Upstream commit ... ]". The
SHAs themselves are the correct SHAs from upstream.

Thanks,
Saravana

Greg KH March 19, 2020, 7:39 a.m. UTC | #2

On Wed, Mar 18, 2020 at 12:10:43PM -0700, Saravana Kannan wrote:
> On Mon, Mar 16, 2020 at 11:54 PM Saravana Kannan <saravanak@google.com> wrote:
> >
> > As mentioned in an earlier email thread [1], 4.19.99 broke the ability
> > to create stateful and stateless device links between the same set of
> > devices when it pulled in a valid bug fix [2]. While the fix was valid,
> > it removes a functionality that was present before the bug fix.
> >
> > This patch series attempts to fix that by pulling in more patches from
> > upstream. I've just done compilation testing so far. But wanted to send
> > out a v1 to see if this patch list was acceptable before I fixed up the
> > commit text format to match what's needed for stable mailing list.
> >
> > Some of the patches are new functionality, but for a first pass, it was
> > easier to pull these in than try and fix the conflicts. If these patches
> > are okay to pull into stable, then all I need to do is fix the commit
> > text.
> 
> I took a closer look at all the patches. Everyone of them is a bug fix
> except Patch 4/6. But Patch 4/6 is a fairly minimal change and I think
> it's easier/cleaner to just pick it up too instead of trying to
> resolve merge conflicts in the stable branch.
> 
> 1/6 - Fixes what appears to be a memory leak bug in upstream.
> 2/6 - Fixes error in initial state of the device link if it's created
> under some circumstances.
> 3/6 - Fixes a ref count bug in upstream. Looks like it can lead to memory leaks?
> 4/6 - Adds a minor feature to kick off a probe attempt of a consumer
> 5/6 - Fixes the break in functionality that happened in 4.19.99
> 6/6 - Fixes bug in 5/6 (upstream bug)
> 
> Greg
> 
> Do these patches look okay for you to pull into 4.19 stable? If so,
> please let me know if you need me to send v2 with commit fix up.
> 
> The only fix up needed is to these patches at this point is changing
> "(cherry picked from commit ...)" with "[ Upstream commit ... ]". The
> SHAs themselves are the correct SHAs from upstream.

These all look good to me, now all queued up, thanks.

greg k-h

Saravana Kannan March 20, 2020, 5:29 a.m. UTC | #3

On Thu, Mar 19, 2020 at 12:39 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Mar 18, 2020 at 12:10:43PM -0700, Saravana Kannan wrote:
> > On Mon, Mar 16, 2020 at 11:54 PM Saravana Kannan <saravanak@google.com> wrote:
> > >
> > > As mentioned in an earlier email thread [1], 4.19.99 broke the ability
> > > to create stateful and stateless device links between the same set of
> > > devices when it pulled in a valid bug fix [2]. While the fix was valid,
> > > it removes a functionality that was present before the bug fix.
> > >
> > > This patch series attempts to fix that by pulling in more patches from
> > > upstream. I've just done compilation testing so far. But wanted to send
> > > out a v1 to see if this patch list was acceptable before I fixed up the
> > > commit text format to match what's needed for stable mailing list.
> > >
> > > Some of the patches are new functionality, but for a first pass, it was
> > > easier to pull these in than try and fix the conflicts. If these patches
> > > are okay to pull into stable, then all I need to do is fix the commit
> > > text.
> >
> > I took a closer look at all the patches. Everyone of them is a bug fix
> > except Patch 4/6. But Patch 4/6 is a fairly minimal change and I think
> > it's easier/cleaner to just pick it up too instead of trying to
> > resolve merge conflicts in the stable branch.
> >
> > 1/6 - Fixes what appears to be a memory leak bug in upstream.
> > 2/6 - Fixes error in initial state of the device link if it's created
> > under some circumstances.
> > 3/6 - Fixes a ref count bug in upstream. Looks like it can lead to memory leaks?
> > 4/6 - Adds a minor feature to kick off a probe attempt of a consumer
> > 5/6 - Fixes the break in functionality that happened in 4.19.99
> > 6/6 - Fixes bug in 5/6 (upstream bug)
> >
> > Greg
> >
> > Do these patches look okay for you to pull into 4.19 stable? If so,
> > please let me know if you need me to send v2 with commit fix up.
> >
> > The only fix up needed is to these patches at this point is changing
> > "(cherry picked from commit ...)" with "[ Upstream commit ... ]". The
> > SHAs themselves are the correct SHAs from upstream.
>
> These all look good to me, now all queued up, thanks.

Awesome, thanks!

-Saravana