From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM list <linux-pm@vger.kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Alan Stern <stern@rowland.harvard.edu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Tomeu Vizoso <tomeu.vizoso@collabora.com>,
Mark Brown <broonie@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Lukas Wunner <lukas@wunner.de>, Kevin Hilman <khilman@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
"Luis R. Rodriguez" <mcgrof@suse.com>
Subject: Re: [RFC/RFT][PATCH v2 0/7] Functional dependencies between devices
Date: Thu, 08 Sep 2016 23:35:09 +0200 [thread overview]
Message-ID: <1725309.5hZIR6bGbC@vostro.rjw.lan> (raw)
In-Reply-To: <27296716.H9VWo8ShOm@vostro.rjw.lan>
On Thursday, September 08, 2016 11:25:44 PM Rafael J. Wysocki wrote:
> Hi Everyone,
>
> This is a refresh of the functional dependencies series that I posted last
> year and which has picked up by Marek quite recently. For reference, appended
> is my introductory message sent previously (which may be slightly outdated now).
>
> As last time, the first patch rearranges the code around __device_release_driver()
> a bit to prepare it for the next one (it actually hasn't changed AFAICS).
>
> The second patch introduces the actual device links mechanics, but without
> system suspend/resume and runtime PM support which are added by the subsequent
> patches.
>
> Some bugs found by Marek during his work on these patches should be fixed
> here. In particular, the endless recursion in device_reorder_to_tail()
> which simply was broken before.
>
> There are two additional patches to address the issue with runtime PM support
> that occured when runtime PM was disabled for some suppliers due to a PM
> sleep transition in progress. Those patches simply make runtime PM helpers
> return 0 in that case which may be controversial, so please let me know if
> there are concerns about those.
>
> The way device_link_add() works is a bit different, as it takes an additional
> status argument now. That makes it possible to create a link in any state,
> with extra care of course, and should address the problem pointed to by Lukas
> during the previous discussion.
>
> Also some comments from Tomeu have been addressed.
>
> This hasn't been really tested yet and I'm sort of relying on Marek to test
> it, because he has a use case ready. Hence, the RFT tag on the series.
>
> Overall, please let me know what you think.
>
> Thanks,
> Rafael
>
>
> Introduction:
>
> As discussed in the recent "On-demand device probing" thread and in a Kernel
> Summit session earlier today, there is a problem with handling cases where
> functional dependencies between devices are involved.
>
> What I mean by a "functional dependency" is when the driver of device B needs
> both device A and its driver to be present and functional to be able to work.
> This implies that the driver of A needs to be working for B to be probed
> successfully and it cannot be unbound from the device before the B's driver.
> This also has certain consequences for power management of these devices
> (suspend/resume and runtime PM ordering).
>
> So I want to be able to represent those functional dependencies between devices
> and I'd like the driver core to track them and act on them in certain cases
> where they matter. The argument for doing that in the driver core is that
> there are quite a few distinct use cases related to that, they are relatively
> hard to get right in a driver (if one wants to address all of them properly)
> and it only gets worse if multiplied by the number of drivers potentially
> needing to do it. Morever, at least one case (asynchronous system suspend/resume)
> cannot be handled in a single driver at all, because it requires the driver of A
> to wait for B to suspend (during system suspend) and the driver of B to wait for
> A to resume (during system resume).
>
> My idea is to represent a supplier-consumer dependency between devices (or
> more precisely between device+driver combos) as a "link" object containing
> pointers to the devices in question, a list node for each of them and some
> additional information related to the management of those objects, ie.
> something like:
>
> struct device_link {
> struct device *supplier;
> struct list_head supplier_node;
> struct device *consumer;
> struct list_head consumer_node;
> <flags, status etc>
> };
>
> In general, there will be two lists of those things per device, one list
> of links to consumers and one list of links to suppliers.
>
> In that picture, links will be created by calling, say:
>
> int device_add_link(struct device *me, struct device *my_supplier, unsigned int flags);
>
> and they will be deleted by the driver core when not needed any more. The
> creation of a link should also cause dpm_list and the list used during shutdown
> to be reordered if needed.
>
> In principle, it seems usefult to consider two types of links, one created
> at device registration time (when registering the second device from the linked
> pair, whichever it is) and one created at probe time (of the consumer device).
> I'll refer to them as "permanent" and "probe-time" links, respectively.
>
> The permanent links (created at device registration time) will stay around
> until one of the linked devices is unregistered (at which time the driver
> core will drop the link along with the device going away). The probe-time
> ones will be dropped (automatically) at the consumer device driver unbind time.
>
> There's a question about what if the supplier device is being unbound before
> the consumer one (for example, as a result of a hotplug event). My current
> view on that is that the consumer needs to be force-unbound in that case too,
> but I guess I may be persuaded otherwise given sufficiently convincing
> arguments. Anyway, there are reasons to do that, like for example it may
> help with the synchronization. Namely, if there's a rule that suppliers
> cannot be unbound before any consumers linked to them, than the list of links
> to suppliers for a consumer can only change at its registration/probe or
> unbind/remove times (which simplifies things quite a bit).
>
> With that, the permanent links existing at the probe time for a consumer
> device can be used to check whether or not to defer the probing of it
> even before executing its probe callback. In turn, system suspend
> synchronization should be a matter of calling device_pm_wait_for_dev()
> for all consumers of a supplier device, in analogy with dpm_wait_for_children(),
> and so on.
>
> Of course, the new lists have to be stable during those operations and ensuring
> that is going to be somewhat tricky (AFAICS right now at least), but apart from
> that the whole concept looks reasonably straightforward to me.
> --
The Mark's address is broken in this series. Again, sadly.
Really sorry about that and please fix it up when you reply.
Thanks,
Rafael
next prev parent reply other threads:[~2016-09-08 21:29 UTC|newest]
Thread overview: 138+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-08 21:25 [RFC/RFT][PATCH v2 0/7] Functional dependencies between devices Rafael J. Wysocki
2016-09-08 21:26 ` [RFC/RFT][PATCH v2 1/7] driver core: Add a wrapper around __device_release_driver() Rafael J. Wysocki
2016-09-08 21:27 ` [RFC/RFT][PATCH v2 2/7] driver core: Functional dependencies tracking support Rafael J. Wysocki
2016-09-09 8:25 ` Ulf Hansson
2016-09-09 12:06 ` Mark Brown
2016-09-09 14:13 ` Ulf Hansson
2016-09-15 1:11 ` Rafael J. Wysocki
2016-09-11 13:40 ` Lukas Wunner
2016-09-11 20:43 ` Lukas Wunner
2016-09-14 1:21 ` Rafael J. Wysocki
2016-09-14 8:28 ` Lukas Wunner
2016-09-14 13:17 ` Rafael J. Wysocki
2016-09-08 21:28 ` [RFC/RFT][PATCH v2 3/7] PM / sleep: Make async suspend/resume of devices use device links Rafael J. Wysocki
2016-09-10 13:31 ` Lukas Wunner
2016-09-10 22:12 ` Rafael J. Wysocki
2016-09-08 21:29 ` [RFC/RFT][PATCH v2 4/7] PM / runtime: Pass flags argument to __pm_runtime_disable() Rafael J. Wysocki
2016-09-08 21:29 ` [RFC/RFT][PATCH v2 5/7] PM / runtime: Flag to indicate PM sleep transitions in progress Rafael J. Wysocki
2016-09-12 14:07 ` Lukas Wunner
2016-09-12 21:25 ` Rafael J. Wysocki
2016-09-12 22:52 ` Lukas Wunner
2016-09-13 7:21 ` Marek Szyprowski
2016-09-13 23:59 ` Rafael J. Wysocki
2016-09-08 21:30 ` [RFC/RFT][PATCH v2 6/7] PM / runtime: Use device links Rafael J. Wysocki
2016-09-12 9:47 ` Lukas Wunner
2016-09-12 13:57 ` Rafael J. Wysocki
2016-09-14 1:19 ` Rafael J. Wysocki
2016-09-08 21:31 ` [RFC/RFT][PATCH v2 7/7] PM / runtime: Optimize the use of " Rafael J. Wysocki
2016-09-08 21:35 ` Rafael J. Wysocki [this message]
2016-09-10 11:39 ` [RFC/RFT][PATCH v2 0/7] Functional dependencies between devices Lukas Wunner
2016-09-10 22:04 ` Rafael J. Wysocki
2016-09-13 17:57 ` Lukas Wunner
2016-09-13 23:18 ` Rafael J. Wysocki
2016-09-18 12:39 ` Lukas Wunner
[not found] ` <CGME20160913095858eucas1p267ec2397c9e4577f94557e4a38498164@eucas1p2.samsung.com>
2016-09-13 9:58 ` Marek Szyprowski
2016-09-13 22:41 ` Rafael J. Wysocki
2016-09-18 11:23 ` Lukas Wunner
2016-09-15 22:03 ` [RFC/RFT][PATCH v3 0/5] " Rafael J. Wysocki
2016-09-15 22:04 ` [Resend][RFC/RFT][PATCH v3 1/5] driver core: Add a wrapper around __device_release_driver() Rafael J. Wysocki
2016-09-15 22:06 ` [RFC/RFT][PATCH v3 2/5] driver core: Functional dependencies tracking support Rafael J. Wysocki
2016-09-16 7:53 ` Marek Szyprowski
2016-09-16 12:06 ` Rafael J. Wysocki
2016-09-16 12:33 ` [Update][RFC/RFT][PATCH " Rafael J. Wysocki
2016-09-19 22:46 ` Lukas Wunner
2016-09-23 13:03 ` Lukas Wunner
2016-09-23 13:42 ` Rafael J. Wysocki
2016-09-26 16:51 ` Lukas Wunner
2016-09-27 12:16 ` Rafael J. Wysocki
2016-09-27 8:54 ` Lukas Wunner
2016-09-27 11:52 ` Rafael J. Wysocki
2016-09-28 10:43 ` Lukas Wunner
2016-09-28 11:31 ` Rafael J. Wysocki
2016-09-29 10:36 ` Lukas Wunner
2016-09-15 22:06 ` [RFC/RFT][PATCH v3 3/5] PM / sleep: Make async suspend/resume of devices use device links Rafael J. Wysocki
2016-09-15 22:07 ` [RFC/RFT][PATCH v3 4/5] PM / runtime: Use " Rafael J. Wysocki
2016-09-15 22:07 ` [RFC/RFT][PATCH v3 5/5] PM / runtime: Optimize the use of " Rafael J. Wysocki
2016-09-16 7:25 ` [RFC/RFT][PATCH v3 0/5] Functional dependencies between devices Marek Szyprowski
2016-09-16 7:57 ` Marek Szyprowski
2016-09-16 12:04 ` Rafael J. Wysocki
2016-09-27 12:34 ` Lukas Wunner
2016-09-28 0:33 ` Rafael J. Wysocki
2016-09-28 11:42 ` Lukas Wunner
2016-09-29 0:51 ` Rafael J. Wysocki
2016-11-15 18:50 ` Lukas Wunner
2016-09-29 0:24 ` [PATCH v4 " Rafael J. Wysocki
2016-09-29 0:25 ` [Resend][PATCH v4 1/5] driver core: Add a wrapper around __device_release_driver() Rafael J. Wysocki
2016-09-29 0:38 ` [PATCH v4 2/5] driver core: Functional dependencies tracking support Rafael J. Wysocki
2016-10-01 7:43 ` Lukas Wunner
2016-10-01 23:32 ` Rafael J. Wysocki
2016-09-29 0:38 ` [Resend][PATCH v4 3/5] PM / sleep: Make async suspend/resume of devices use device links Rafael J. Wysocki
2016-09-29 0:40 ` [PATCH v4 4/5] PM / runtime: Use " Rafael J. Wysocki
2016-09-29 0:41 ` [Rebase][PATCH v4 5/5] PM / runtime: Optimize the use of " Rafael J. Wysocki
2016-09-29 6:58 ` [PATCH v4 0/5] Functional dependencies between devices Marek Szyprowski
2016-09-29 12:27 ` Rafael J. Wysocki
2016-10-02 23:13 ` Lukas Wunner
2016-10-10 12:36 ` [PATCH v5 " Rafael J. Wysocki
2016-10-10 12:37 ` [Resend][PATCH v5 1/5] driver core: Add a wrapper around __device_release_driver() Rafael J. Wysocki
2016-10-10 12:51 ` [PATCH v5 2/5] driver core: Functional dependencies tracking support Rafael J. Wysocki
2016-10-26 11:19 ` Lukas Wunner
2016-10-27 15:25 ` Greg Kroah-Hartman
2016-10-28 9:57 ` Lukas Wunner
2016-11-07 21:22 ` Luis R. Rodriguez
2016-11-08 6:45 ` Greg Kroah-Hartman
2016-11-08 19:21 ` Luis R. Rodriguez
2016-11-08 19:43 ` Greg Kroah-Hartman
2016-11-08 20:58 ` Luis R. Rodriguez
2016-11-09 6:45 ` Greg Kroah-Hartman
2016-11-09 9:36 ` Andrzej Hajda
2016-11-09 9:41 ` Greg Kroah-Hartman
2016-11-13 16:58 ` Lukas Wunner
2016-11-10 0:43 ` Rafael J. Wysocki
2016-11-10 0:59 ` Luis R. Rodriguez
2016-11-10 7:14 ` Laurent Pinchart
2016-11-10 22:04 ` Luis R. Rodriguez
2016-11-10 22:40 ` Greg Kroah-Hartman
2016-11-11 0:08 ` Laurent Pinchart
2016-11-13 10:59 ` Greg Kroah-Hartman
2016-11-14 14:50 ` Luis R. Rodriguez
2016-11-14 8:15 ` Geert Uytterhoeven
2016-11-10 8:46 ` Geert Uytterhoeven
2016-11-10 22:12 ` Luis R. Rodriguez
2016-10-27 15:32 ` Greg Kroah-Hartman
2016-11-07 21:39 ` Luis R. Rodriguez
2016-11-10 1:07 ` Rafael J. Wysocki
2016-11-10 7:05 ` Laurent Pinchart
2016-11-10 23:09 ` Luis R. Rodriguez
2016-11-13 17:34 ` Lukas Wunner
2016-11-14 13:48 ` Luis R. Rodriguez
2016-11-14 15:48 ` Lukas Wunner
2016-11-14 16:00 ` Luis R. Rodriguez
2016-10-10 12:54 ` [PATCH v5 3/5] PM / sleep: Make async suspend/resume of devices use device links Rafael J. Wysocki
2016-10-10 12:56 ` [PATCH v5 4/5] PM / runtime: Use " Rafael J. Wysocki
2016-10-20 13:17 ` [Update][PATCH " Rafael J. Wysocki
2016-10-10 12:57 ` [Rebase][PATCH v5 5/5] PM / runtime: Optimize the use of " Rafael J. Wysocki
2016-10-18 10:46 ` [PATCH v5 0/5] Functional dependencies between devices Marek Szyprowski
2016-10-19 11:57 ` Rafael J. Wysocki
2016-10-20 10:21 ` Marek Szyprowski
2016-10-20 12:54 ` Rafael J. Wysocki
2016-10-27 15:32 ` Greg Kroah-Hartman
[not found] ` <5811F0CF.5000204@huawei.com>
2016-10-28 9:39 ` Lukas Wunner
2016-11-02 20:55 ` Hanjun Guo
2016-10-30 16:22 ` [PATCH v6 " Rafael J. Wysocki
2016-10-30 16:28 ` [Resend][PATCH v6 3/5] PM / sleep: Make async suspend/resume of devices use device links Rafael J. Wysocki
2016-10-30 16:29 ` [Resend][PATCH v6 1/5] driver core: Add a wrapper around __device_release_driver() Rafael J. Wysocki
2016-10-30 16:32 ` [PATCH v6 2/5] driver core: Functional dependencies tracking support Rafael J. Wysocki
2016-10-30 16:32 ` [PATCH v6 4/5] PM / runtime: Use device links Rafael J. Wysocki
2016-12-18 14:01 ` Lukas Wunner
2016-12-18 15:53 ` Rafael J. Wysocki
2016-12-18 16:37 ` Lukas Wunner
2016-12-19 12:38 ` Rafael J. Wysocki
2016-10-30 16:32 ` [Resend][PATCH v6 5/5] PM / runtime: Optimize the use of " Rafael J. Wysocki
2016-10-30 16:40 ` [PATCH v6 0/5] Functional dependencies between devices Rafael J. Wysocki
2016-10-31 17:47 ` Greg Kroah-Hartman
2016-11-01 3:50 ` Rafael J. Wysocki
2016-11-02 7:58 ` Marek Szyprowski
2016-11-05 12:10 ` Greg Kroah-Hartman
2016-11-07 21:15 ` Luis R. Rodriguez
2016-11-08 6:36 ` Marek Szyprowski
2016-11-08 20:14 ` Luis R. Rodriguez
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=1725309.5hZIR6bGbC@vostro.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=khilman@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=m.szyprowski@samsung.com \
--cc=mcgrof@suse.com \
--cc=stern@rowland.harvard.edu \
--cc=tomeu.vizoso@collabora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).