Re: [RFD] Functional dependencies between devices
On 30 October 2015 at 23:52, Greg Kroah-Hartman
wrote:
> On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
>> 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;
>>
>> };
>>
>> 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);
>
> At first glance, I like this, nice. Now to see how well it can be
> implemented :)
Hi Greg,
what's your opinion on using this to order device probes so we don't
try to probe a device that we know it has unfulfilled dependencies?
Regards,
Tomeu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] Functional dependencies between devices
Hi, Sorry for late response. On 11/24/2015 05:28 PM, Rafael J. Wysocki wrote: > On Tuesday, November 24, 2015 03:57:09 PM Andrzej Hajda wrote: >> On 11/19/2015 11:04 PM, Rafael J. Wysocki wrote: >>> On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote: On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote: > On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote: >> Hi Rafael, >> >>> [cut] >>> > So the operations that need to be taken care of are: > - Probe (suppliers need to be probed before consumers if the dependencies > are > known beforehand). > - System suspend/resume (suppliers need to be suspended after consumers > and > resumed before them) which may be asynchronous (so simple re-ordering > doesn't > help). > - Runtime PM (suppliers should not be suspended if the consumers are not > suspended). I though provider's frameworks are taking care of it already. For example clock provider cannot suspend until there are prepared/enabled clocks. Similar enabled regulators, phys should block provider from runtime pm suspending. Are there situations/frameworks which requires additional care? >>> Yes, there are, AFAICS. >>> >>> A somewhat extreme example of this is when an AML routine needed for power >>> management of one device uses something like a GPIO line or an I2C link >>> provided by another one. We don't even have a way to track that kind of >>> thing at the provider framework level and the only information we can get >>> from the platform firmware is "this device depends on that one". >>> >>> Plus, even if the frameworks track those things, when a device suspend is >>> requested, the question really is "Are there any devices that have to be >>> suspended before this one?" rather than "Are other devices using resources >>> provided by this one?". Of course, you may argue that answering the second >>> one will allow you to answer the first one too (that is based on the >>> assumption >>> that you can always track all cases of resource utilization which may not be >>> entirely realistic), but getting that answer in a non-racy way may be rather >>> expensive. >> In such extreme case the device itself can play a role of resource. >> But in my proposal I do not try to answer which devices/resource depends >> on which ones, we do not need such info. >> It is just matter of notifying direct consumers about change of availability >> of given resource, and this notification is necessary anyway if we want >> to support hot resource/drivers (un-)plugging. > Well, we've been supporting hotplug for quite a while without that ... > > You seem to be referring to situations in which individual resources may go > away and drivers are supposed to reconfigure themselves on the fly. > > This is not what the $subject proposal is about. Currently if you undbind some driver from the device and the driver is a provider with active consumers usually it results in crashes/oopses. So I wouldn't say that hot resources/drivers unplugging is supported. > > - System shutdown (shutdown callbacks should be executed for consumers > first). > - Driver unbind (a supplier driver cannot be unbound before any of its > consumer > drivers). > > In principle you can use resource tracking to figure out all of the > involved > dependencies, but that would require walking complicated data structures > unless > you add an intermediate "device dependency" layer which is going to be > analogous > to the one discussed here. It should be enough if provider notifies consumers that the resource will be unavailable. >>> To me, this isn't going in the right direction. You should be asking "Am I >>> allowed to suspend now?" instead of saying "I'm suspending and now you deal >>> with it" to somebody. Why is that so? Because the other end may simply be >>> unable to deal with the situation in the first place. >> No. It is just saying "I want to suspend now, please not use my resources". >> In such case consumer should unprepare clocks, disable regulators, etc. >> But if it is not able to do so it just ignores the request. Provider >> will know >> anyway that his resources are in use and will not suspend. > This goes beyond the runtime PM framework which is based on device reference > counting and for system suspend it's not practical at all, because one driver > refusing to suspend aborts the entire operation system-wide. Aren't current suspend callbacks designed that way? Documentation/power/devices.txt says clearly: "If any of these callbacks returns an error, the system won't enter the desired low-power state. Instead the PM core will unwind its actions by resuming all the devices that were suspended." > >>> My idea is to represent a supplier-consumer dependency between devices >>> (or >>> more precisely between device+driver combos) as a "link"
Re: [RFD] Functional dependencies between devices
On Tuesday, November 24, 2015 03:57:09 PM Andrzej Hajda wrote:
> On 11/19/2015 11:04 PM, Rafael J. Wysocki wrote:
> > On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote:
> >> On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote:
> >>> On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote:
> Hi Rafael,
>
> > [cut]
> >
> >>> So the operations that need to be taken care of are:
> >>> - Probe (suppliers need to be probed before consumers if the dependencies
> >>> are
> >>> known beforehand).
> >>> - System suspend/resume (suppliers need to be suspended after consumers
> >>> and
> >>> resumed before them) which may be asynchronous (so simple re-ordering
> >>> doesn't
> >>> help).
> >>> - Runtime PM (suppliers should not be suspended if the consumers are not
> >>> suspended).
> >> I though provider's frameworks are taking care of it already. For example
> >> clock provider cannot suspend until there are prepared/enabled clocks.
> >> Similar enabled regulators, phys should block provider from runtime pm
> >> suspending.
> >>
> >> Are there situations/frameworks which requires additional care?
> > Yes, there are, AFAICS.
> >
> > A somewhat extreme example of this is when an AML routine needed for power
> > management of one device uses something like a GPIO line or an I2C link
> > provided by another one. We don't even have a way to track that kind of
> > thing at the provider framework level and the only information we can get
> > from the platform firmware is "this device depends on that one".
> >
> > Plus, even if the frameworks track those things, when a device suspend is
> > requested, the question really is "Are there any devices that have to be
> > suspended before this one?" rather than "Are other devices using resources
> > provided by this one?". Of course, you may argue that answering the second
> > one will allow you to answer the first one too (that is based on the
> > assumption
> > that you can always track all cases of resource utilization which may not be
> > entirely realistic), but getting that answer in a non-racy way may be rather
> > expensive.
>
> In such extreme case the device itself can play a role of resource.
> But in my proposal I do not try to answer which devices/resource depends
> on which ones, we do not need such info.
> It is just matter of notifying direct consumers about change of availability
> of given resource, and this notification is necessary anyway if we want
> to support hot resource/drivers (un-)plugging.
Well, we've been supporting hotplug for quite a while without that ...
You seem to be referring to situations in which individual resources may go
away and drivers are supposed to reconfigure themselves on the fly.
This is not what the $subject proposal is about.
> >
> >>> - System shutdown (shutdown callbacks should be executed for consumers
> >>> first).
> >>> - Driver unbind (a supplier driver cannot be unbound before any of its
> >>> consumer
> >>> drivers).
> >>>
> >>> In principle you can use resource tracking to figure out all of the
> >>> involved
> >>> dependencies, but that would require walking complicated data structures
> >>> unless
> >>> you add an intermediate "device dependency" layer which is going to be
> >>> analogous
> >>> to the one discussed here.
> >> It should be enough if provider notifies consumers that the resource
> >> will be unavailable.
> > To me, this isn't going in the right direction. You should be asking "Am I
> > allowed to suspend now?" instead of saying "I'm suspending and now you deal
> > with it" to somebody. Why is that so? Because the other end may simply be
> > unable to deal with the situation in the first place.
>
> No. It is just saying "I want to suspend now, please not use my resources".
> In such case consumer should unprepare clocks, disable regulators, etc.
> But if it is not able to do so it just ignores the request. Provider
> will know
> anyway that his resources are in use and will not suspend.
This goes beyond the runtime PM framework which is based on device reference
counting and for system suspend it's not practical at all, because one driver
refusing to suspend aborts the entire operation system-wide.
> > 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;
> >
> > };
> >
> > In general, there will be two lists of those things per device, one list
> > of links to consumers and one list of links to
Re: [RFD] Functional dependencies between devices
On 11/19/2015 11:04 PM, Rafael J. Wysocki wrote:
> On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote:
>> On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote:
>>> On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote:
Hi Rafael,
> [cut]
>
>>> So the operations that need to be taken care of are:
>>> - Probe (suppliers need to be probed before consumers if the dependencies
>>> are
>>> known beforehand).
>>> - System suspend/resume (suppliers need to be suspended after consumers and
>>> resumed before them) which may be asynchronous (so simple re-ordering
>>> doesn't
>>> help).
>>> - Runtime PM (suppliers should not be suspended if the consumers are not
>>> suspended).
>> I though provider's frameworks are taking care of it already. For example
>> clock provider cannot suspend until there are prepared/enabled clocks.
>> Similar enabled regulators, phys should block provider from runtime pm
>> suspending.
>>
>> Are there situations/frameworks which requires additional care?
> Yes, there are, AFAICS.
>
> A somewhat extreme example of this is when an AML routine needed for power
> management of one device uses something like a GPIO line or an I2C link
> provided by another one. We don't even have a way to track that kind of
> thing at the provider framework level and the only information we can get
> from the platform firmware is "this device depends on that one".
>
> Plus, even if the frameworks track those things, when a device suspend is
> requested, the question really is "Are there any devices that have to be
> suspended before this one?" rather than "Are other devices using resources
> provided by this one?". Of course, you may argue that answering the second
> one will allow you to answer the first one too (that is based on the
> assumption
> that you can always track all cases of resource utilization which may not be
> entirely realistic), but getting that answer in a non-racy way may be rather
> expensive.
In such extreme case the device itself can play a role of resource.
But in my proposal I do not try to answer which devices/resource depends
on which ones, we do not need such info.
It is just matter of notifying direct consumers about change of availability
of given resource, and this notification is necessary anyway if we want
to support hot resource/drivers (un-)plugging.
>
>>> - System shutdown (shutdown callbacks should be executed for consumers
>>> first).
>>> - Driver unbind (a supplier driver cannot be unbound before any of its
>>> consumer
>>> drivers).
>>>
>>> In principle you can use resource tracking to figure out all of the involved
>>> dependencies, but that would require walking complicated data structures
>>> unless
>>> you add an intermediate "device dependency" layer which is going to be
>>> analogous
>>> to the one discussed here.
>> It should be enough if provider notifies consumers that the resource
>> will be unavailable.
> To me, this isn't going in the right direction. You should be asking "Am I
> allowed to suspend now?" instead of saying "I'm suspending and now you deal
> with it" to somebody. Why is that so? Because the other end may simply be
> unable to deal with the situation in the first place.
No. It is just saying "I want to suspend now, please not use my resources".
In such case consumer should unprepare clocks, disable regulators, etc.
But if it is not able to do so it just ignores the request. Provider
will know
anyway that his resources are in use and will not suspend.
>
> 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;
>
> };
>
> 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
Re: [RFD] Functional dependencies between devices
On 11/21/2015 03:04 PM, Mark Brown wrote: > On Thu, Nov 19, 2015 at 07:50:45AM +0100, Andrzej Hajda wrote: >> On 11/17/2015 02:55 PM, Mark Brown wrote: >>> This is going to be really common but I'm not sure I see a problem with >>> it in terms of what Raphael is proposing - could you go into more detail >>> on the problem you see here? >> If clock provider is not a device driver and it depends on clocks of >> another clock >> provider you cannot 'translate' this dependency as dependency between >> devices, > What makes you say that this is the case? There should be nothing > stopping us having dependencies between two devices of the same type. To be clear I described situation that one clock provider uses clock of another clock provider and consumer is not modeled as device. > >> so this RFD does not cover them. >> Additionally if you look into kernel there are many calls in form >> 'clk_get(NULL, name)', >> it suggests that not only clock providers are consumers without >> underlying device driver. > Like I said in my earlier reply: > > | > - many clock providers, irq domains are not provided by devices, > > | That seems like something we can and possibly should change if we want. > > This applies just as much to consumers as to providers. OK, then it is just something to do :) Regards Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] Functional dependencies between devices
On Thu, Nov 19, 2015 at 07:50:45AM +0100, Andrzej Hajda wrote: > On 11/17/2015 02:55 PM, Mark Brown wrote: > > This is going to be really common but I'm not sure I see a problem with > > it in terms of what Raphael is proposing - could you go into more detail > > on the problem you see here? > If clock provider is not a device driver and it depends on clocks of > another clock > provider you cannot 'translate' this dependency as dependency between > devices, What makes you say that this is the case? There should be nothing stopping us having dependencies between two devices of the same type. > so this RFD does not cover them. > Additionally if you look into kernel there are many calls in form > 'clk_get(NULL, name)', > it suggests that not only clock providers are consumers without > underlying device driver. Like I said in my earlier reply: | > - many clock providers, irq domains are not provided by devices, | That seems like something we can and possibly should change if we want. This applies just as much to consumers as to providers. signature.asc Description: PGP signature
Re: [RFD] Functional dependencies between devices
On Thu, Nov 19, 2015 at 02:18:59PM +0100, Thierry Reding wrote: > On Tue, Nov 17, 2015 at 01:55:49PM +, Mark Brown wrote: > > On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote: > > > On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote: > > > this scenario: > > > - many clock providers, irq domains are not provided by devices, > > That seems like something we can and possibly should change if we want. > It's not very trivial, unfortunately. I had a crack at that a long time > ago, but the problem is that these devices all need to be available very > early during boot, at which point devices aren't registered yet. With > all the progress on probe deferral and the on-demand probing work this > might be less of an issue nowadays, I haven't looked at it for quite a > while. I believe it's a lot easier to do that now but ICBW. We've started needing to put these things into firmware so that we can refer to them from clients so we pretty much have to deal with it. I've not had to worry about it too much directly myself recently though. > That said, one technique I've occasionally resorted to is to have some > early code, be it one of the OF table things or an initcall, set up a > basic environment, typically using global variables (yuck!), but then > provide a proper driver that knows how to take these things over when > its time comes. That's not a perfect solution, but at least it gives you > a proper struct device to work with. Indeed, that's also how things like the console work. signature.asc Description: PGP signature
Re: [RFD] Functional dependencies between devices
On Thursday, November 19, 2015 11:04:00 PM Rafael J. Wysocki wrote: > On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote: > > On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote: > > > On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote: > > >> Hi Rafael, > > >> > > [cut] > > > > So the operations that need to be taken care of are: > > > - Probe (suppliers need to be probed before consumers if the dependencies > > > are > > > known beforehand). > > > - System suspend/resume (suppliers need to be suspended after consumers > > > and > > > resumed before them) which may be asynchronous (so simple re-ordering > > > doesn't > > > help). > > > - Runtime PM (suppliers should not be suspended if the consumers are not > > > suspended). > > I though provider's frameworks are taking care of it already. For example > > clock provider cannot suspend until there are prepared/enabled clocks. > > Similar enabled regulators, phys should block provider from runtime pm > > suspending. > > > > Are there situations/frameworks which requires additional care? > > Yes, there are, AFAICS. > > A somewhat extreme example of this is when an AML routine needed for power > management of one device uses something like a GPIO line or an I2C link > provided by another one. We don't even have a way to track that kind of > thing at the provider framework level and the only information we can get > from the platform firmware is "this device depends on that one". > > Plus, even if the frameworks track those things, when a device suspend is > requested, the question really is "Are there any devices that have to be > suspended before this one?" rather than "Are other devices using resources > provided by this one?". Of course, you may argue that answering the second > one will allow you to answer the first one too (that is based on the > assumption > that you can always track all cases of resource utilization which may not be > entirely realistic), but getting that answer in a non-racy way may be rather > expensive. More importantly, the point here is not to help drivers etc to do the right things. It is to make it possible for them to provide the driver core with enough information so it can take care of doing the right things by itself. If that works as intended, the creation of a link between two devices will automatically cause the driver core to take care of ordering things in the right way etc in all of the cases I listed, so the drivers of those two devices don't need to worry about that any more. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] Functional dependencies between devices
On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote:
> On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote:
> > On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote:
> >> Hi Rafael,
> >>
[cut]
> > So the operations that need to be taken care of are:
> > - Probe (suppliers need to be probed before consumers if the dependencies
> > are
> > known beforehand).
> > - System suspend/resume (suppliers need to be suspended after consumers and
> > resumed before them) which may be asynchronous (so simple re-ordering
> > doesn't
> > help).
> > - Runtime PM (suppliers should not be suspended if the consumers are not
> > suspended).
> I though provider's frameworks are taking care of it already. For example
> clock provider cannot suspend until there are prepared/enabled clocks.
> Similar enabled regulators, phys should block provider from runtime pm
> suspending.
>
> Are there situations/frameworks which requires additional care?
Yes, there are, AFAICS.
A somewhat extreme example of this is when an AML routine needed for power
management of one device uses something like a GPIO line or an I2C link
provided by another one. We don't even have a way to track that kind of
thing at the provider framework level and the only information we can get
from the platform firmware is "this device depends on that one".
Plus, even if the frameworks track those things, when a device suspend is
requested, the question really is "Are there any devices that have to be
suspended before this one?" rather than "Are other devices using resources
provided by this one?". Of course, you may argue that answering the second
one will allow you to answer the first one too (that is based on the assumption
that you can always track all cases of resource utilization which may not be
entirely realistic), but getting that answer in a non-racy way may be rather
expensive.
> > - System shutdown (shutdown callbacks should be executed for consumers
> > first).
> > - Driver unbind (a supplier driver cannot be unbound before any of its
> > consumer
> > drivers).
> >
> > In principle you can use resource tracking to figure out all of the involved
> > dependencies, but that would require walking complicated data structures
> > unless
> > you add an intermediate "device dependency" layer which is going to be
> > analogous
> > to the one discussed here.
>
> It should be enough if provider notifies consumers that the resource
> will be unavailable.
To me, this isn't going in the right direction. You should be asking "Am I
allowed to suspend now?" instead of saying "I'm suspending and now you deal
with it" to somebody. Why is that so? Because the other end may simply be
unable to deal with the situation in the first place.
> >
> >>> 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;
> >>>
> >>> };
> >>>
> >>> 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.
> >> What about permanent links in case provider is unregistered? Should they
> >> disappear? It will not make consumers happy. What if the provider will be
> >> re-registered.
> > If the device object is gone, it cannot be pointed to by any links (on any
> > end)
> > any more. That's just physically impossible. :-)
>
> So the link will disappear and the 'consumer' will have dependencies
> fulfilled.
That's why in my opinion the rule should be that all consume
Re: [RFD] Functional dependencies between devices
On Tue, Nov 17, 2015 at 01:55:49PM +, Mark Brown wrote: > On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote: > > On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote: > > > this scenario: > > - many clock providers, irq domains are not provided by devices, > > That seems like something we can and possibly should change if we want. It's not very trivial, unfortunately. I had a crack at that a long time ago, but the problem is that these devices all need to be available very early during boot, at which point devices aren't registered yet. With all the progress on probe deferral and the on-demand probing work this might be less of an issue nowadays, I haven't looked at it for quite a while. But I fully agree that the current state of setting up providers without a device structure is suboptimal precisely because it prevents generic infrastructure like the one Rafael proposed from just working. That said, one technique I've occasionally resorted to is to have some early code, be it one of the OF table things or an initcall, set up a basic environment, typically using global variables (yuck!), but then provide a proper driver that knows how to take these things over when its time comes. That's not a perfect solution, but at least it gives you a proper struct device to work with. Thierry signature.asc Description: PGP signature
Re: [RFD] Functional dependencies between devices
On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote: > On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote: >> Hi Rafael, >> >> Please forgive me late reply, but I have missed this thread before. >> >> On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote: >>> Hi All, >>> >>> 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). >> I think the real dependency is when some entity asks for some resource (irq, >> clock, gpio,...). > Well, a dependency is when one entity uses a resource provided by another one, > not only when it explicitly asks for that resource. But that's a very high > level of abstraction IMO. > >> Usually the entity is some device driver during probing and >> the resource is provided by some bound device but there are many exceptions >> for >> this scenario: >> - many clock providers, irq domains are not provided by devices, >> - there are also dependencies between clock providers, ie. some clock >> provider >> requires clocks provided by another clock provider, so the entity is also >> not a >> device driver, >> - there are resources which can be requested after probe - case of >> componentized >> devices (DRM for example), more precisely they can be requested during probe >> of >> random component or master of componentized device, >> - another case are requests for some additional/optional resources after >> device >> driver probe, for example phone usually does not require HDMI related >> resources >> until user attach HDMI cable, >> - (semi-)circular dependencies - 1st device provides clock used by other >> devices >> which provides other resources used by the 1st device, scenario present in >> some >> video pipelines, like camera subsystem + sensors. >> >> These examples shows that dependencies between bound device drivers are just >> subset of bigger issue, maybe it is worth to look for more general solution. > That really depends on the goal. > > The goal here is to add a mechanism allowing the driver core to carry out > certain operations in the right order. The operations in question are carried > out on devices using drivers (and perhaps bus types, PM domains etc), so using > a representation of links between devices seems adequate to me. > >>> 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). >> Could you elaborate these distinct use cases. I am curious because I have >> proposed resource tracking framework [1] which should solve most of the >> issues >> described here. It was not designed to solve suspend/resume issues, but it >> could >> be easily extended to support it, I suppose. >> >> [1]: https://lkml.org/lkml/2014/12/10/342 > So the operations that need to be taken care of are: > - Probe (suppliers need to be probed before consumers if the dependencies are > known beforehand). > - System suspend/resume (suppliers need to be suspended after consumers and > resumed before them) which may be asynchronous (so simple re-ordering > doesn't > help). > - Runtime PM (suppliers should not be suspended if the consumers are not > suspended). I though provider's frameworks are taking care of it already. For example clock provider cannot suspend until there are prepared/enabled clocks. Similar enabled regulators, phys should block provider from runtime pm suspending. Are there situations/frameworks which requires additional care? > - System shutdown (shutdown callbacks should be executed for consumers first). > - Driver unbind (a supplier driver cannot be unbound before any of its > consumer > drivers). > > In principle you can use resource tracking to figure out all of the involved > dependencies, but that would r
Re: [RFD] Functional dependencies between devices
On 11/17/2015 02:55 PM, Mark Brown wrote: > On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote: > > Please fix your mail client to word wrap within paragraphs at something > substantially less than 80 columns. Doing this makes your messages much > easier to read and reply to. > >> On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote: >> this scenario: >> - many clock providers, irq domains are not provided by devices, > That seems like something we can and possibly should change if we want. > >> - there are also dependencies between clock providers, ie. some clock >> provider >> requires clocks provided by another clock provider, so the entity is also >> not a >> device driver, > This is going to be really common but I'm not sure I see a problem with > it in terms of what Raphael is proposing - could you go into more detail > on the problem you see here? If clock provider is not a device driver and it depends on clocks of another clock provider you cannot 'translate' this dependency as dependency between devices, so this RFD does not cover them. Additionally if you look into kernel there are many calls in form 'clk_get(NULL, name)', it suggests that not only clock providers are consumers without underlying device driver. Regards Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] Functional dependencies between devices
On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote: > Hi Rafael, > > Please forgive me late reply, but I have missed this thread before. > > On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote: > > Hi All, > > > > 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). > > I think the real dependency is when some entity asks for some resource (irq, > clock, gpio,...). Well, a dependency is when one entity uses a resource provided by another one, not only when it explicitly asks for that resource. But that's a very high level of abstraction IMO. > Usually the entity is some device driver during probing and > the resource is provided by some bound device but there are many exceptions > for > this scenario: > - many clock providers, irq domains are not provided by devices, > - there are also dependencies between clock providers, ie. some clock provider > requires clocks provided by another clock provider, so the entity is also not > a > device driver, > - there are resources which can be requested after probe - case of > componentized > devices (DRM for example), more precisely they can be requested during probe > of > random component or master of componentized device, > - another case are requests for some additional/optional resources after > device > driver probe, for example phone usually does not require HDMI related > resources > until user attach HDMI cable, > - (semi-)circular dependencies - 1st device provides clock used by other > devices > which provides other resources used by the 1st device, scenario present in > some > video pipelines, like camera subsystem + sensors. > > These examples shows that dependencies between bound device drivers are just > subset of bigger issue, maybe it is worth to look for more general solution. That really depends on the goal. The goal here is to add a mechanism allowing the driver core to carry out certain operations in the right order. The operations in question are carried out on devices using drivers (and perhaps bus types, PM domains etc), so using a representation of links between devices seems adequate to me. > > 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). > > Could you elaborate these distinct use cases. I am curious because I have > proposed resource tracking framework [1] which should solve most of the issues > described here. It was not designed to solve suspend/resume issues, but it > could > be easily extended to support it, I suppose. > > [1]: https://lkml.org/lkml/2014/12/10/342 So the operations that need to be taken care of are: - Probe (suppliers need to be probed before consumers if the dependencies are known beforehand). - System suspend/resume (suppliers need to be suspended after consumers and resumed before them) which may be asynchronous (so simple re-ordering doesn't help). - Runtime PM (suppliers should not be suspended if the consumers are not suspended). - System shutdown (shutdown callbacks should be executed for consumers first). - Driver unbind (a supplier driver cannot be unbound before any of its consumer drivers). In principle you can use resource tracking to figure out all of the involved dependencies, but that would require walking complicated data structures unless you add an intermediate "device dependency" layer which is going to be analogous to the one discussed here. > > 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 relate
Re: [RFD] Functional dependencies between devices
On Tue, Nov 17, 2015 at 03:31:29PM -0500, Alan Stern wrote: > Also, there's a real problem that needs to be solved concerning how > resources are identified in the absence of DT (or ACPI or something > similar). So long as we can add new dependencies at probe time we should always be able to figure things out when the driver figures out it needs the resources. Realistically we'll always have some information - if we don't have firmware we'll have a board file. signature.asc Description: PGP signature
Re: [RFD] Functional dependencies between devices
On Tue, 17 Nov 2015, Andrzej Hajda wrote: > > 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). > > Could you elaborate these distinct use cases. I am curious because I have > proposed resource tracking framework [1] which should solve most of the issues > described here. It was not designed to solve suspend/resume issues, but it > could > be easily extended to support it, I suppose. > > [1]: https://lkml.org/lkml/2014/12/10/342 The dependencies Rafael has in mind include the following (and undoubtedly include more): The consumer device requires some resource from a provider device before it can be probed. Resources can be clocks, phys, gpios, and so on. The consumer device can't be at full power unless a provider device is also at full power. > Regarding fundamental things, maybe it is just my impression but parsing > private > DT device nodes by kernel core assumes that convention about using resource > specifiers in DT is a strict rule, it should not be true. > > As I wrote before I have send some early RFC with framework which solves most > of > the problems described here[1], the missing part is suspend/resume support > which > should be quite easy to add, I suspect. Moreover it solves problem of device > driver hot bind/unbind. > Could you take a look at it, I will be glad to know it is worth to continue > work > on it? It looks like the major difference is that you propose to use callbacks or notifications to do a lot of the work. For example, a driver probing a device could register a bunch of dependencies on various resources, and a callback would be invoked when all those dependencies were satisfied, at which point the probe procedure could complete. No need for deferrals. It's an interesting idea. I'm not sure how well it applies to power dependencies, though. Also, there's a real problem that needs to be solved concerning how resources are identified in the absence of DT (or ACPI or something similar). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] Functional dependencies between devices
On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote: Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote: > this scenario: > - many clock providers, irq domains are not provided by devices, That seems like something we can and possibly should change if we want. > - there are also dependencies between clock providers, ie. some clock provider > requires clocks provided by another clock provider, so the entity is also not > a > device driver, This is going to be really common but I'm not sure I see a problem with it in terms of what Raphael is proposing - could you go into more detail on the problem you see here? > - another case are requests for some additional/optional resources after > device > driver probe, for example phone usually does not require HDMI related > resources > until user attach HDMI cable, Normally the drivers we need would all be loaded based on the hardware we have in the system, it would be very unusual to dynamically request new resources at runtime to deal with a reconfiguration. Doing so seems likely to result in fragility. signature.asc Description: PGP signature
Re: [RFD] Functional dependencies between devices
Hi Rafael,
It is just re-send of the previous message with fixed e-mail.
Please forgive me late reply, but I have missed this thread before.
On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
> Hi All,
>
> 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).
I think the real dependency is when some entity asks for some resource (irq,
clock, gpio,...). Usually the entity is some device driver during probing and
the resource is provided by some bound device but there are many exceptions for
this scenario:
- many clock providers, irq domains are not provided by devices,
- there are also dependencies between clock providers, ie. some clock provider
requires clocks provided by another clock provider, so the entity is also not a
device driver,
- there are resources which can be requested after probe - case of componentized
devices (DRM for example), more precisely they can be requested during probe of
random component or master of componentized device,
- another case are requests for some additional/optional resources after device
driver probe, for example phone usually does not require HDMI related resources
until user attach HDMI cable,
- (semi-)circular dependencies - 1st device provides clock used by other devices
which provides other resources used by the 1st device, scenario present in some
video pipelines, like camera subsystem + sensors.
These examples shows that dependencies between bound device drivers are just
subset of bigger issue, maybe it is worth to look for more general solution.
>
> 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).
Could you elaborate these distinct use cases. I am curious because I have
proposed resource tracking framework [1] which should solve most of the issues
described here. It was not designed to solve suspend/resume issues, but it could
be easily extended to support it, I suppose.
[1]: https://lkml.org/lkml/2014/12/10/342
>
> 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;
>
> };
>
> 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.
What about permanent links in case provider is unregistered? Should they
disappear? It will not make consumers happy. What if the provider will b
Re: [RFD] Functional dependencies between devices
Hi Rafael,
Please forgive me late reply, but I have missed this thread before.
On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
> Hi All,
>
> 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).
I think the real dependency is when some entity asks for some resource (irq,
clock, gpio,...). Usually the entity is some device driver during probing and
the resource is provided by some bound device but there are many exceptions for
this scenario:
- many clock providers, irq domains are not provided by devices,
- there are also dependencies between clock providers, ie. some clock provider
requires clocks provided by another clock provider, so the entity is also not a
device driver,
- there are resources which can be requested after probe - case of componentized
devices (DRM for example), more precisely they can be requested during probe of
random component or master of componentized device,
- another case are requests for some additional/optional resources after device
driver probe, for example phone usually does not require HDMI related resources
until user attach HDMI cable,
- (semi-)circular dependencies - 1st device provides clock used by other devices
which provides other resources used by the 1st device, scenario present in some
video pipelines, like camera subsystem + sensors.
These examples shows that dependencies between bound device drivers are just
subset of bigger issue, maybe it is worth to look for more general solution.
>
> 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).
Could you elaborate these distinct use cases. I am curious because I have
proposed resource tracking framework [1] which should solve most of the issues
described here. It was not designed to solve suspend/resume issues, but it could
be easily extended to support it, I suppose.
[1]: https://lkml.org/lkml/2014/12/10/342
>
> 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;
>
> };
>
> 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.
What about permanent links in case provider is unregistered? Should they
disappear? It will not make consumers happy. What if the provider will be
re-registered.
>
> There's a question about what if the sup
Re: [RFD] Functional dependencies between devices
On Monday, November 09, 2015 01:32:04 PM Thierry Reding wrote: > On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote: > [...] > > 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. > > I think this would be a huge step towards making the kernel more robust > with little driver or subsystem code having to be duplicated. Currently > most provider/consumer subsystems are fragile in that there isn't proper > reference counting. Many subsystems will happily allow you to remove any > of the provider, regardless of whether or not it has consumers. Most of > the subsystems will make sure that modules can't be unloaded, but beyond > that won't be able to prevent drivers from being unbound (either when a > device is unplugged or unbound via sysfs). Even with proper reference > counting there is no easy way to deal with devices going away (you'd > need some sort of revoke semantics implemented for all providers, and > consumers must be able to handle that situation gracefully). > > Implementing a force-unbind policy would make this a whole lot easier. > Dangling resources will automatically become a thing of the past. The > downside of course is that force-unbinding consumers may not always be > the most user-friendly course of action. Consider an SD/MMC slot that > uses a GPIO as card-detect pin. Unbinding the provider of the GPIO > would cause the SD/ MMC controller to be unbound, hence unmounting the > filesystem that it provided. That filesystem might have been the root > filesystem. Well, the problem is that device_release_driver() cannot fail, so it pretty much has to unbind everything that is not going to work after the driver is unbound from the device. > We discussed similar use-cases a while back and you proposed making the > force-unbind policy be two-staged: reject unbind (-EBUSY) if there are > any consumers, and force-unbind consumers if the provider was forcibly > unbound (or caused by hot-unplug of the backing device). That sounds > like a good compromise to me. That can be done for bus types having device_offline/online() support, but the number of these is quite limited at this point. The "offline" operation, as opposed to device_release_driver(), can return an error code to indicate that the device cannot be taken offline at this time. So, if offlining a supplier would require offlining all consumers of it, that may be made fail in certain situation. However, that would require quite a bit of additional structure (and complexity) in pretty much all bus types, so I wouldn't start with it at least. > That said I can also imagine subsystems where a reliable mechanism is in > place to properly hotplug and -unplug providers. The good thing about > the functional dependencies mechanism you propose here is that it's an > optional mechanism that drivers use from ->probe(). Subsystems where a > better mechanism exists can simply choose to do without functional > dependencies. I actually think that those things are at least partly orthogonal. Thanks, Rafael signature.asc Description: This is a digitally signed message part.
Re: [RFD] Functional dependencies between devices
On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote: [...] > 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. I think this would be a huge step towards making the kernel more robust with little driver or subsystem code having to be duplicated. Currently most provider/consumer subsystems are fragile in that there isn't proper reference counting. Many subsystems will happily allow you to remove any of the provider, regardless of whether or not it has consumers. Most of the subsystems will make sure that modules can't be unloaded, but beyond that won't be able to prevent drivers from being unbound (either when a device is unplugged or unbound via sysfs). Even with proper reference counting there is no easy way to deal with devices going away (you'd need some sort of revoke semantics implemented for all providers, and consumers must be able to handle that situation gracefully). Implementing a force-unbind policy would make this a whole lot easier. Dangling resources will automatically become a thing of the past. The downside of course is that force-unbinding consumers may not always be the most user-friendly course of action. Consider an SD/MMC slot that uses a GPIO as card-detect pin. Unbinding the provider of the GPIO would cause the SD/ MMC controller to be unbound, hence unmounting the filesystem that it provided. That filesystem might have been the root filesystem. We discussed similar use-cases a while back and you proposed making the force-unbind policy be two-staged: reject unbind (-EBUSY) if there are any consumers, and force-unbind consumers if the provider was forcibly unbound (or caused by hot-unplug of the backing device). That sounds like a good compromise to me. That said I can also imagine subsystems where a reliable mechanism is in place to properly hotplug and -unplug providers. The good thing about the functional dependencies mechanism you propose here is that it's an optional mechanism that drivers use from ->probe(). Subsystems where a better mechanism exists can simply choose to do without functional dependencies. Thierry signature.asc Description: PGP signature
Re: [RFD] Functional dependencies between devices
On Sat, 31 Oct 2015, Rafael J. Wysocki wrote: > > One possible approach is to have a "wait_for_driver" flag, along with a > > timeout value (or perhaps using a fixed timeout value). When a > > dependency gets registered with this flag set, the function call > > wouldn't return until the target device is bound to a driver or the > > timeout has elapsed. > > > > This would make it easy to insert dependencies at probe time without > > relying on deferred probing. > > I'm not sure about this to be honest. It seems like implementing it might > be sort of tricky. Well, clearly it wouldn't work if probes were serialized and one driver was dependent on another that was going to be probed later. But if probes are asynchronous then it ought to be okay (unless there is a dependency cycle, in which case the situation is hopeless anyway). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] Functional dependencies between devices
On Sat, Oct 31, 2015 at 03:13:09AM +0100, Rafael J. Wysocki wrote: > On Thursday, October 29, 2015 09:15:09 AM Mark Brown wrote: > > This seems like a good plan to me however I am concerned that only > > allowing links to be created at device registration time will prove > > restrictive - it means we're going to ignore anything we figure out > > later on in the boot sequence. > That's not the plan, though. :-) > I'm talking about device registration time or device probe time (for > dependencies that aren't known at the registration time). Oh, so I think allowing things to be added at probe time addresses my concerns - for some reason I'd parsed your mail as talking about registration time only. signature.asc Description: PGP signature
Re: [RFD] Functional dependencies between devices
On Thursday, October 29, 2015 10:31:08 AM Alan Stern wrote: > Good grief, don't you guys ever trim unwanted material from your > emails? I had to erase more than 4 screens worth of useless stuff > before getting to the relevant portions. > > On Thu, 29 Oct 2015, Tomeu Vizoso wrote: > > > >> Also, have you considered that not only drivers request resources? For > > >> example, the on-demand probing series would probe a device that is > > >> needed by an initcall, simplifying synchronization. > > Did Rafael ever say that only drivers could create these functional > dependencies? I don't recall seeing that anywhere. Presumably any > part of the kernel will be allowed to do it. Right. > > > You really need to explain what you mean here or maybe give an example. > > > > There are initcalls that assume that a given resource is available. > > Because of async probes, or because the resource's driver being built > > as a module, or because the resource's driver gained a dependency > > (direct or not), those initcalls break unexpectedly at times. Well, I'm still unsure what initcalls are in question here. > > If resource getters could probe dependencies on-demand, those > > initcalls would be more robust to changes in other parts of the > > codebase. > > > > AFAIUI, your proposal would help with a device's dependencies being > > there when it's probed, but initcalls could still run into unfulfilled > > dependencies. > > One possible approach is to have a "wait_for_driver" flag, along with a > timeout value (or perhaps using a fixed timeout value). When a > dependency gets registered with this flag set, the function call > wouldn't return until the target device is bound to a driver or the > timeout has elapsed. > > This would make it easy to insert dependencies at probe time without > relying on deferred probing. I'm not sure about this to be honest. It seems like implementing it might be sort of tricky. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] Functional dependencies between devices
On Thursday, October 29, 2015 09:15:09 AM Mark Brown wrote: > On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote: > > > So, the question to everybody is whether or not this sounds reasonable or > > there > > are concerns about it and if so what they are. At this point I mostly need > > to > > know if I'm not overlooking anything fundamental at the general level. > > This seems like a good plan to me however I am concerned that only > allowing links to be created at device registration time will prove > restrictive - it means we're going to ignore anything we figure out > later on in the boot sequence. That's not the plan, though. :-) I'm talking about device registration time or device probe time (for dependencies that aren't known at the registration time). > I would be very surprised if we didn't > need that, either from things that get missed or from things that get > allocated dynamically at runtime on systems with flexible hardware, and > it'd also mean that systems can start to benefit from this for suspend > and resume without needing the updates to the firmware parsing support. The reason why I think it should be restricted to the probe/remove and registration/unregistration times is because of PM. More specifically, adding a link to a "supplier" causes additional actions to be taken during PM operations (eg. if the supplier device is suspended at the consumer device resume time, it needs to be resumed in the runtime PM case or waited for in the system resume case) which may be regarded as a change in a way PM is handled. Such changes are only expected to happen at the points I mentioned and may lead to rather undesirable outcomes if made elsewhere. Thanks, Rafael signature.asc Description: This is a digitally signed message part.
Re: [RFD] Functional dependencies between devices
On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
> 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;
>
> };
>
> 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);
At first glance, I like this, nice. Now to see how well it can be
implemented :)
Again, nice job.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] Functional dependencies between devices
On Tue, Oct 27, 2015 at 4:24 PM, Rafael J. Wysocki wrote:
> 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;
>
> };
>
> 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.
I like this idea. I earlier have written that the device core needs to know
the dependencies of devices as a graph. This mechanism does that.
IIUC the mechanism does not inheritly protect against creating
cyclic graphs (you can get stuck in a loop) but that is just the
nature of the things and even deferred probe has the ability
to shoot oneself in the foot. Besides we're not doing computer
science here, we're solving practical problems.
What I further like about the approach is that it can even be used
by archs still doing boardfiles and not using any HW description
mechanism: it is there for anyone. Those platforms can define
dependencies with good old code.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] Functional dependencies between devices
Good grief, don't you guys ever trim unwanted material from your emails? I had to erase more than 4 screens worth of useless stuff before getting to the relevant portions. On Thu, 29 Oct 2015, Tomeu Vizoso wrote: > >> Also, have you considered that not only drivers request resources? For > >> example, the on-demand probing series would probe a device that is > >> needed by an initcall, simplifying synchronization. Did Rafael ever say that only drivers could create these functional dependencies? I don't recall seeing that anywhere. Presumably any part of the kernel will be allowed to do it. > > You really need to explain what you mean here or maybe give an example. > > There are initcalls that assume that a given resource is available. > Because of async probes, or because the resource's driver being built > as a module, or because the resource's driver gained a dependency > (direct or not), those initcalls break unexpectedly at times. > > If resource getters could probe dependencies on-demand, those > initcalls would be more robust to changes in other parts of the > codebase. > > AFAIUI, your proposal would help with a device's dependencies being > there when it's probed, but initcalls could still run into unfulfilled > dependencies. One possible approach is to have a "wait_for_driver" flag, along with a timeout value (or perhaps using a fixed timeout value). When a dependency gets registered with this flag set, the function call wouldn't return until the target device is bound to a driver or the timeout has elapsed. This would make it easy to insert dependencies at probe time without relying on deferred probing. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] Functional dependencies between devices
On 28 October 2015 at 16:54, Rafael J. Wysocki wrote:
> On Wednesday, October 28, 2015 03:26:14 PM Tomeu Vizoso wrote:
>> On 28 October 2015 at 03:15, Rafael J. Wysocki wrote:
>> > On Tuesday, October 27, 2015 04:20:51 PM Tomeu Vizoso wrote:
>> >> On 27 October 2015 at 16:24, Rafael J. Wysocki wrote:
>> >> > Hi All,
>> >> >
>> >> > 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;
>> >> >
>> >> > };
>> >> >
>> >> > 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 sho
Re: [RFD] Functional dependencies between devices
On Wed, Oct 28, 2015 at 04:54:04PM +0100, Rafael J. Wysocki wrote: > Information that is already available at the device registration time should > be used at that time or it makes things harder to follow. > But that really is a tradeoff. If collecting that information requires too > much effort, it may not be worth it. For DT it's going to be a lot eaiser to reliably collect everything in driver specific code, the property names to look at do follow conventions but are driver defined. signature.asc Description: PGP signature
Re: [RFD] Functional dependencies between devices
On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote: > So, the question to everybody is whether or not this sounds reasonable or > there > are concerns about it and if so what they are. At this point I mostly need to > know if I'm not overlooking anything fundamental at the general level. This seems like a good plan to me however I am concerned that only allowing links to be created at device registration time will prove restrictive - it means we're going to ignore anything we figure out later on in the boot sequence. I would be very surprised if we didn't need that, either from things that get missed or from things that get allocated dynamically at runtime on systems with flexible hardware, and it'd also mean that systems can start to benefit from this for suspend and resume without needing the updates to the firmware parsing support. signature.asc Description: PGP signature
Re: [RFD] Functional dependencies between devices
On Wednesday, October 28, 2015 03:26:14 PM Tomeu Vizoso wrote:
> On 28 October 2015 at 03:15, Rafael J. Wysocki wrote:
> > On Tuesday, October 27, 2015 04:20:51 PM Tomeu Vizoso wrote:
> >> On 27 October 2015 at 16:24, Rafael J. Wysocki wrote:
> >> > Hi All,
> >> >
> >> > 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;
> >> >
> >> > };
> >> >
> >> > 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
Re: [RFD] Functional dependencies between devices
On 28 October 2015 at 03:15, Rafael J. Wysocki wrote:
> On Tuesday, October 27, 2015 04:20:51 PM Tomeu Vizoso wrote:
>> On 27 October 2015 at 16:24, Rafael J. Wysocki wrote:
>> > Hi All,
>> >
>> > 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;
>> >
>> > };
>> >
>> > 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.
>> >
>> > So, the question to everybody is whether or not this sounds reasonable or
>> > there
>> > are concerns
Re: [RFD] Functional dependencies between devices
On Tuesday, October 27, 2015 04:20:51 PM Tomeu Vizoso wrote:
> On 27 October 2015 at 16:24, Rafael J. Wysocki wrote:
> > Hi All,
> >
> > 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;
> >
> > };
> >
> > 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.
> >
> > So, the question to everybody is whether or not this sounds reasonable or
> > there
> > are concerns about it and if so what they are. At this point I mostly need
> > to
> > know if I'm not overlooking anything fundamental at the general level.
>
> Sounds really great to me at t
Re: [RFD] Functional dependencies between devices
On 27 October 2015 at 16:24, Rafael J. Wysocki wrote:
> Hi All,
>
> 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;
>
> };
>
> 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.
>
> So, the question to everybody is whether or not this sounds reasonable or
> there
> are concerns about it and if so what they are. At this point I mostly need to
> know if I'm not overlooking anything fundamental at the general level.
Sounds really great to me at the conceptual level, but wonder if you
have already thought of how the permanent links will be inferred.
When I looked at computing dependencies of a device before it's
probed, the concern was that the code that finds the dependencies
duplicated part of the logic when looking resources up.
[RFD] Functional dependencies between devices
Hi All,
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;
};
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.
So, the question to everybody is whether or not this sounds reasonable or there
are concerns about it and if so what they are. At this point I mostly need to
know if I'm not overlooking anything fundamental at the general level.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
