From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
Saravana Kannan <saravanak@google.com>,
Lukas Wunner <lukas@wunner.de>, Jon Hunter <jonathanh@nvidia.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v2] driver core: Remove device link creation limitation
Date: Tue, 23 Jul 2019 09:57:24 +0200 [thread overview]
Message-ID: <20190723075724.GB27243@kroah.com> (raw)
In-Reply-To: <CAJZ5v0h-nWr1vie61U6BzDxns+qmj_3EOFztE_X-CGgtzkz=ZA@mail.gmail.com>
On Tue, Jul 23, 2019 at 09:34:54AM +0200, Rafael J. Wysocki wrote:
> Hi Greg,
>
> On Tue, Jul 16, 2019 at 5:21 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Subject: [PATCH] driver core: Remove device link creation limitation
> >
> > If device_link_add() is called for a consumer/supplier pair with an
> > existing device link between them and the existing link's type is
> > not in agreement with the flags passed to that function by its
> > caller, NULL will be returned. That is seriously inconvenient,
> > because it forces the callers of device_link_add() to worry about
> > what others may or may not do even if that is not relevant to them
> > for any other reasons.
> >
> > It turns out, however, that this limitation can be made go away
> > relatively easily.
> >
> > The underlying observation is that if DL_FLAG_STATELESS has been
> > passed to device_link_add() in flags for the given consumer/supplier
> > pair at least once, calling either device_link_del() or
> > device_link_remove() to release the link returned by it should work,
> > but there are no other requirements associated with that flag. In
> > turn, if at least one of the callers of device_link_add() for the
> > given consumer/supplier pair has not passed DL_FLAG_STATELESS to it
> > in flags, the driver core should track the status of the link and act
> > on it as appropriate (ie. the link should be treated as "managed").
> > This means that DL_FLAG_STATELESS needs to be set for managed device
> > links and it should be valid to call device_link_del() or
> > device_link_remove() to drop references to them in certain
> > sutiations.
> >
> > To allow that to happen, introduce a new (internal) device link flag
> > called DL_FLAG_MANAGED and make device_link_add() set it automatically
> > whenever DL_FLAG_STATELESS is not passed to it. Also make it take
> > additional references to existing device links that were previously
> > stateless (that is, with DL_FLAG_STATELESS set and DL_FLAG_MANAGED
> > unset) and will need to be managed going forward and initialize
> > their status (which has been DL_STATE_NONE so far).
> >
> > Accordingly, when a managed device link is dropped automatically
> > by the driver core, make it clear DL_FLAG_MANAGED, reset the link's
> > status back to DL_STATE_NONE and drop the reference to it associated
> > with DL_FLAG_MANAGED instead of just deleting it right away (to
> > allow it to stay around in case it still needs to be released
> > explicitly by someone).
> >
> > With that, since setting DL_FLAG_STATELESS doesn't mean that the
> > device link in question is not managed any more, replace all of the
> > status-tracking checks against DL_FLAG_STATELESS with analogous
> > checks against DL_FLAG_MANAGED and update the documentation to
> > reflect these changes.
> >
> > While at it, make device_link_add() reject flags that it does not
> > recognize, including DL_FLAG_MANAGED.
> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Reviewed-by: Saravana Kannan <saravanak@google.com>
> > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> Do I need to resend this?
>
> I know that posting new things during a merge window is not most
> convenient, sorry about that.
No, it's in my queue, give me a few days to dig out from my huge pending
patch list, no need to resend it.
thanks,
greg k-h
next prev parent reply other threads:[~2019-07-23 7:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-16 15:21 [PATCH v2] driver core: Remove device link creation limitation Rafael J. Wysocki
2019-07-16 18:49 ` Saravana Kannan
2019-07-23 7:34 ` Rafael J. Wysocki
2019-07-23 7:57 ` Greg Kroah-Hartman [this message]
2019-07-29 15:48 ` Dmitry Osipenko
2019-07-29 20:46 ` Saravana Kannan
2019-07-29 21:24 ` Rafael J. Wysocki
2019-07-29 21:43 ` Saravana Kannan
2019-07-29 22:03 ` Rafael J. Wysocki
2019-07-29 22:13 ` Saravana Kannan
2019-07-29 21:50 ` Rafael J. Wysocki
2019-07-30 7:04 ` Greg Kroah-Hartman
2019-07-30 8:54 ` Jon Hunter
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=20190723075724.GB27243@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=m.szyprowski@samsung.com \
--cc=rafael@kernel.org \
--cc=saravanak@google.com \
--cc=ulf.hansson@linaro.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.