Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1222085 > unrolled thread
| Started by | Thierry Reding <thierry.reding@gmail.com> |
|---|---|
| First post | 2015-09-10 12:20 +0200 |
| Last post | 2015-09-11 16:10 +0200 |
| Articles | 20 on this page of 46 — 6 participants |
Back to article view | Back to linux.kernel
[PATCH] driver core: Ensure proper suspend/resume ordering Thierry Reding <thierry.reding@gmail.com> - 2015-09-10 12:20 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Grygorii Strashko <grygorii.strashko@ti.com> - 2015-09-10 13:00 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-10 23:50 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Thierry Reding <thierry.reding@gmail.com> - 2015-09-11 14:10 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-11 21:10 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-12 00:10 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-12 19:50 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-15 02:50 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-15 16:30 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-16 02:40 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Grygorii Strashko <grygorii.strashko@ti.com> - 2015-09-16 15:50 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-16 21:30 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-17 01:40 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Grygorii Strashko <grygorii.strashko@ti.com> - 2015-09-17 17:50 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-18 02:00 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-18 02:10 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Thierry Reding <thierry.reding@gmail.com> - 2015-09-15 18:20 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-15 21:20 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-16 03:10 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Grygorii Strashko <grygorii.strashko@ti.com> - 2015-09-16 15:40 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-16 19:00 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-16 19:10 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Thierry Reding <thierry.reding@gmail.com> - 2015-09-16 15:20 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-16 21:30 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-17 02:00 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-17 04:10 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-17 19:10 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-17 20:50 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-17 23:10 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-18 02:20 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Thierry Reding <thierry.reding@gmail.com> - 2015-09-18 18:00 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-19 01:10 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Thierry Reding <thierry.reding@gmail.com> - 2015-09-21 11:00 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-21 16:40 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-22 02:00 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-22 03:30 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-22 02:40 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-17 07:50 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-17 20:20 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-17 21:30 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-12 00:20 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Thierry Reding <thierry.reding@gmail.com> - 2015-09-15 18:00 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-16 03:00 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Grygorii Strashko <grygorii.strashko@ti.com> - 2015-09-16 15:40 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-17 02:30 +0200
Re: [PATCH] driver core: Ensure proper suspend/resume ordering Alan Stern <stern@rowland.harvard.edu> - 2015-09-11 16:10 +0200
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-16 19:00 +0200 |
| Message-ID | <q9odP-1QO-11@gated-at.bofh.it> |
| In reply to | #1226085 |
On Wed, 16 Sep 2015, Grygorii Strashko wrote:
> >> The core prohibits new devices from being registered. It does not
> >> prohibit probes of existing devices, because they currently do not
> >> affect the dpm_list.
>
> Seems I missed smth, but I can't find the place in Kernel that prohibits
> creation of new devices during suspend.
>
> Could someone point me on, please?
In Documentation/power/devices.txt, there is a section describing the
various phases of system suspend. The part about the "prepare" phase
says:
1. The prepare phase is meant to prevent races by preventing new devices
from being registered; the PM core would never know that all the
children of a device had been suspended if new children could be
registered at will. (By contrast, devices may be unregistered at any
time.) Unlike the other suspend-related phases, during the prepare
phase the device tree is traversed top-down.
After the prepare callback method returns, no new children may be
registered below the device. The method may also prepare the device or
driver in some way for the upcoming system power transition, but it
should not put the device into a low-power state.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-16 19:10 +0200 |
| Message-ID | <q9onv-2h2-11@gated-at.bofh.it> |
| In reply to | #1225650 |
On Wed, 16 Sep 2015, Rafael J. Wysocki wrote: > > The core prohibits new devices from being registered. It does not > > prohibit probes of existing devices, because they currently do not > > affect the dpm_list. > > Which may be a mistake, because it does affect callbacks executed during > suspend/resume (after successful probe the device potentially has a different > set of PM callbacks than before). > > > In general, we rely on subsystems not to do any probing once a device > > is suspended. It's probably reasonable to ask them not to do any > > probing once a device has gone through the "prepare" stage. > > Right. > > Question is when it should be allowed to probe again. I guess at the same > time we allow registrations to to take place again? That would make the most sense. Particularly since registration automatically causes probing to occur. Now, we do allow registration below a device as soon as the ->resume callback returns, whereas devices don't get added back to the dpm_list until after the "complete" phase is totally finished. If a previously-existing device gets probed in between, it would be moved off the dpm_prepared_list before its ->complete callback was invoked, which means its ->complete wouldn't get called at all. Perhaps this would be okay; it depends on the subsystem. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Thierry Reding <thierry.reding@gmail.com> |
|---|---|
| Date | 2015-09-16 15:20 +0200 |
| Message-ID | <q9kMW-5w2-23@gated-at.bofh.it> |
| In reply to | #1225518 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Sep 15, 2015 at 03:18:19PM -0400, Alan Stern wrote: > On Tue, 15 Sep 2015, Thierry Reding wrote: > > > > There are a few things to watch out for. Since the dpm_list gets > > > modified during system sleep transitions, we would have to make sure > > > that nothing gets probed during those times. In principle, that's what > > > the "prepare" stage is meant for, but there's still a race. As long as > > > no other kernel thread (such as the deferred probing mechanism) tries > > > to probe a device once everything has been frozen, we should be okay. > > > But if not, there will be trouble -- after the ->prepare callback runs, > > > the device is no longer on the dpm_list and so we don't want this patch > > > to put it back on that list. > > > > Perhaps moving to the end of the list needs to be a little smarter. That > > is it could check whether the device has been prepared for suspension or > > not and only move when it hasn't? > > Maybe. But doesn't that mean it won't solve your problem completely? It would solve the problem completely if probing was prohibited during the suspend/resume cycle. But if that were true there'd be no need to special-case in the first place. > > Then again, shouldn't the core even prohibit new probes once the suspend > > has been triggered? Sounds like asking for a lot of trouble if it didn't > > ... > > The core prohibits new devices from being registered. It does not > prohibit probes of existing devices, because they currently do not > affect the dpm_list. My understanding was that the core was guaranteed not to call suspend or resume callbacks for devices that haven't completed probe. At least I've never seen any driver code specifically check in their suspend or resume callbacks that they've been probed successfully. Allowing probes while a suspend is happening sounds racy. > In general, we rely on subsystems not to do any probing once a device > is suspended. It's probably reasonable to ask them not to do any > probing once a device has gone through the "prepare" stage. Perhaps the reason why we seem to be talking across purposes is that I haven't thought much about devices where the bus does all the heavy lifting. So suspending the device from a bus' perspective makes sense even if the device hasn't been bound. And yes, I agree that preventing a probe for a device that has been prepared for suspension sounds like a very reasonable thing to do. > > > There's also an issue about other types of dependencies. For instance, > > > it's conceivable that device B might be discovered and depend on device > > > A, even before A has been bound to a driver. (B might be discovered by > > > A's subsystem rather than A's driver.) In that case, moving A to the > > > end of the list would cause B to come before A even though B depends on > > > A. Of course, deferred probing already has this problem. > > > > But that's exactly the problem that I'm seeing. > > Not quite. > > > B isn't discovered by > > A's subsystem, but the type of dependency is the same. A in this case > > would be the GPIO controller and B the gpio-keys device. B clearly > > depends on A, but deferred probe currently moves A to the end of the > > list but not A, hence why the problem occurs. > > The difference is that in my example, B can be probed before A. In > your case it can't. Therefore the patch works for your case but not > for mine. How would that even work in practice? Essentially you have a dependency between two devices and no way of guaranteeing any ordering. Either the dependency is completely optional, in which case the ordering of the dpm_list must be irrelevant to the interaction, or the drivers make too many assumptions and it is only working by accident. > > That's also a problem that I think this patch solves. By moving every > > device to the end of the list before it is probed we ensure that the > > dpm_list is ordered in the same way as the probe order. For this to work > > the precondition of course is that drivers know about the dependencies > > and will defer probe if necessary. > > Do I understand correctly? You're saying a driver must defer a probe > if the device it's probing depends on another device which hasn't > been bound yet. That does not sound like a reasonable sort of > requirement -- we might know about the dependency but we shouldn't have > to check whether the prerequisite device has been bound. I guess that depends on the kind of dependency you have. For most cases that I'm aware of the dependencies are required dependencies. That is, a consumer uses a resource registered by a provider. The provider will register the resource at probe time, so if the consumer is probed before the provider, then the resource it needs isn't there. For a required dependency that implies that the consumer must defer probe until the provider has been bound because it simply can't continue without getting access to the resource first. I'm slightly confused by your statement. If a consumer depends on a provider for a resource, how can we finish the consumer's probe without checking that the provider has been bound? It's true that we don't technically check for the device to have been bound, but the end result is the same. Unless I misunderstand what you're saying we'd need to have some mechanism to notify the consumer (after it's been probed) that the provider of it's resource has become available. Thierry
[toc] | [prev] | [next] | [standalone]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-16 21:30 +0200 |
| Message-ID | <q9qz0-5ll-15@gated-at.bofh.it> |
| In reply to | #1226073 |
On Wed, 16 Sep 2015, Thierry Reding wrote: > > > Perhaps moving to the end of the list needs to be a little smarter. That > > > is it could check whether the device has been prepared for suspension or > > > not and only move when it hasn't? > > > > Maybe. But doesn't that mean it won't solve your problem completely? > > It would solve the problem completely if probing was prohibited during > the suspend/resume cycle. But if that were true there'd be no need to > special-case in the first place. It's possible that this approach will help. We'll see. It would also help if your patch checked to see if the device has any children, and avoided moving it to the end of the list if it does. In fact, that might be sufficient to avoid almost all problems. > > > Then again, shouldn't the core even prohibit new probes once the suspend > > > has been triggered? Sounds like asking for a lot of trouble if it didn't > > > ... > > > > The core prohibits new devices from being registered. It does not > > prohibit probes of existing devices, because they currently do not > > affect the dpm_list. > > My understanding was that the core was guaranteed not to call suspend or > resume callbacks for devices that haven't completed probe. No, that's not so. The core invokes suspend and resume callbacks for all registered devices. > At least I've > never seen any driver code specifically check in their suspend or resume > callbacks that they've been probed successfully. Now that wouldn't make any sense, would it? A driver's suspend or resume callback wouldn't be invoked in the first place unless the driver had already been probed for that device. So there's no point in checking whether the probe has occurred. > Allowing probes while a > suspend is happening sounds racy. Yes, it does. It definitely isn't a good idea. During a sleep transition all user threads are frozen. So are some kernel threads, but not all of them. It's possible that one of the running kernel threads might want to do a probe -- something in a workqueue, for example. That's the only way it could happen. > > In general, we rely on subsystems not to do any probing once a device > > is suspended. It's probably reasonable to ask them not to do any > > probing once a device has gone through the "prepare" stage. > > Perhaps the reason why we seem to be talking across purposes is that I > haven't thought much about devices where the bus does all the heavy > lifting. So suspending the device from a bus' perspective makes sense > even if the device hasn't been bound. Yes. > And yes, I agree that preventing a probe for a device that has been > prepared for suspension sounds like a very reasonable thing to do. > > > > > There's also an issue about other types of dependencies. For instance, > > > > it's conceivable that device B might be discovered and depend on device > > > > A, even before A has been bound to a driver. (B might be discovered by > > > > A's subsystem rather than A's driver.) In that case, moving A to the > > > > end of the list would cause B to come before A even though B depends on > > > > A. Of course, deferred probing already has this problem. > > > > > > But that's exactly the problem that I'm seeing. > > > > Not quite. > > > > > B isn't discovered by > > > A's subsystem, but the type of dependency is the same. A in this case > > > would be the GPIO controller and B the gpio-keys device. B clearly > > > depends on A, but deferred probe currently moves A to the end of the > > > list but not A, hence why the problem occurs. > > > > The difference is that in my example, B can be probed before A. In > > your case it can't. Therefore the patch works for your case but not > > for mine. > > How would that even work in practice? Essentially you have a dependency > between two devices and no way of guaranteeing any ordering. Either the > dependency is completely optional, in which case the ordering of the > dpm_list must be irrelevant to the interaction, or the drivers make too > many assumptions and it is only working by accident. Rafael gave a good example. A device behind a PCIe port can't be detected until the port has been registered, so the port will always get on the dpm_list before the other device does. But both devices can be added before the port has been probed. This dependency is not optional and it is guaranteed. But it's not related to anything the drivers do. > > > That's also a problem that I think this patch solves. By moving every > > > device to the end of the list before it is probed we ensure that the > > > dpm_list is ordered in the same way as the probe order. For this to work > > > the precondition of course is that drivers know about the dependencies > > > and will defer probe if necessary. > > > > Do I understand correctly? You're saying a driver must defer a probe > > if the device it's probing depends on another device which hasn't > > been bound yet. That does not sound like a reasonable sort of > > requirement -- we might know about the dependency but we shouldn't have > > to check whether the prerequisite device has been bound. > > I guess that depends on the kind of dependency you have. For most cases > that I'm aware of the dependencies are required dependencies. That is, a > consumer uses a resource registered by a provider. The provider will > register the resource at probe time, so if the consumer is probed before > the provider, then the resource it needs isn't there. For a required > dependency that implies that the consumer must defer probe until the > provider has been bound because it simply can't continue without getting > access to the resource first. Okay. It would be a good idea to restrict your patch to handle only that particular kind of dependency, if you can think of any way to do this. > I'm slightly confused by your statement. If a consumer depends on a > provider for a resource, how can we finish the consumer's probe without > checking that the provider has been bound? It's true that we don't > technically check for the device to have been bound, but the end result > is the same. > > Unless I misunderstand what you're saying we'd need to have some > mechanism to notify the consumer (after it's been probed) that the > provider of it's resource has become available. You misunderstand me. Yes, I agree that your patch handles the case where a consumer depends on a provider for a resource. But it doesn't handle the case where one device depends on another for something other than a resource (or perhaps for a resource that can be provided even in the absence of a driver). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-09-17 02:00 +0200 |
| Message-ID | <q9uMh-2R6-7@gated-at.bofh.it> |
| In reply to | #1226412 |
On Wednesday, September 16, 2015 03:22:37 PM Alan Stern wrote: > On Wed, 16 Sep 2015, Thierry Reding wrote: > > > > > Perhaps moving to the end of the list needs to be a little smarter. That > > > > is it could check whether the device has been prepared for suspension or > > > > not and only move when it hasn't? > > > > > > Maybe. But doesn't that mean it won't solve your problem completely? > > > > It would solve the problem completely if probing was prohibited during > > the suspend/resume cycle. But if that were true there'd be no need to > > special-case in the first place. > > It's possible that this approach will help. We'll see. > > It would also help if your patch checked to see if the device has any > children, and avoided moving it to the end of the list if it does. In > fact, that might be sufficient to avoid almost all problems. I agree. In any case if a device that already has children is about to be probed, this is sort of a corner case anyway and should be handled as such. > > > > Then again, shouldn't the core even prohibit new probes once the suspend > > > > has been triggered? Sounds like asking for a lot of trouble if it didn't > > > > ... > > > > > > The core prohibits new devices from being registered. It does not > > > prohibit probes of existing devices, because they currently do not > > > affect the dpm_list. > > > > My understanding was that the core was guaranteed not to call suspend or > > resume callbacks for devices that haven't completed probe. > > No, that's not so. The core invokes suspend and resume callbacks for > all registered devices. And those may be bus type callbacks that decide whether or not to call driver callbacks. Having a driver bound to a device is not necessary for a bus type callback to succeed in general. > > At least I've > > never seen any driver code specifically check in their suspend or resume > > callbacks that they've been probed successfully. > > Now that wouldn't make any sense, would it? A driver's suspend or > resume callback wouldn't be invoked in the first place unless the > driver had already been probed for that device. So there's no point in > checking whether the probe has occurred. > > > Allowing probes while a > > suspend is happening sounds racy. > > Yes, it does. It definitely isn't a good idea. > > During a sleep transition all user threads are frozen. So are some > kernel threads, but not all of them. It's possible that one of the > running kernel threads might want to do a probe -- something in a > workqueue, for example. That's the only way it could happen. A hotplug event or something like that I suppose, but those should be deferred to post resume time too. > > > In general, we rely on subsystems not to do any probing once a device > > > is suspended. It's probably reasonable to ask them not to do any > > > probing once a device has gone through the "prepare" stage. > > > > Perhaps the reason why we seem to be talking across purposes is that I > > haven't thought much about devices where the bus does all the heavy > > lifting. So suspending the device from a bus' perspective makes sense > > even if the device hasn't been bound. > > Yes. Precisely. > > And yes, I agree that preventing a probe for a device that has been > > prepared for suspension sounds like a very reasonable thing to do. > > > > > > > There's also an issue about other types of dependencies. For instance, > > > > > it's conceivable that device B might be discovered and depend on device > > > > > A, even before A has been bound to a driver. (B might be discovered by > > > > > A's subsystem rather than A's driver.) In that case, moving A to the > > > > > end of the list would cause B to come before A even though B depends on > > > > > A. Of course, deferred probing already has this problem. > > > > > > > > But that's exactly the problem that I'm seeing. > > > > > > Not quite. > > > > > > > B isn't discovered by > > > > A's subsystem, but the type of dependency is the same. A in this case > > > > would be the GPIO controller and B the gpio-keys device. B clearly > > > > depends on A, but deferred probe currently moves A to the end of the > > > > list but not A, hence why the problem occurs. > > > > > > The difference is that in my example, B can be probed before A. In > > > your case it can't. Therefore the patch works for your case but not > > > for mine. > > > > How would that even work in practice? Essentially you have a dependency > > between two devices and no way of guaranteeing any ordering. Either the > > dependency is completely optional, in which case the ordering of the > > dpm_list must be irrelevant to the interaction, or the drivers make too > > many assumptions and it is only working by accident. > > Rafael gave a good example. A device behind a PCIe port can't be > detected until the port has been registered, so the port will always > get on the dpm_list before the other device does. But both devices can > be added before the port has been probed. > > This dependency is not optional and it is guaranteed. But it's not > related to anything the drivers do. > > > > > That's also a problem that I think this patch solves. By moving every > > > > device to the end of the list before it is probed we ensure that the > > > > dpm_list is ordered in the same way as the probe order. For this to work > > > > the precondition of course is that drivers know about the dependencies > > > > and will defer probe if necessary. > > > > > > Do I understand correctly? You're saying a driver must defer a probe > > > if the device it's probing depends on another device which hasn't > > > been bound yet. That does not sound like a reasonable sort of > > > requirement -- we might know about the dependency but we shouldn't have > > > to check whether the prerequisite device has been bound. > > > > I guess that depends on the kind of dependency you have. For most cases > > that I'm aware of the dependencies are required dependencies. That is, a > > consumer uses a resource registered by a provider. The provider will > > register the resource at probe time, so if the consumer is probed before > > the provider, then the resource it needs isn't there. For a required > > dependency that implies that the consumer must defer probe until the > > provider has been bound because it simply can't continue without getting > > access to the resource first. > > Okay. It would be a good idea to restrict your patch to handle only > that particular kind of dependency, if you can think of any way to do > this. Agreed. I've been postulating exactly that from the start, but I might not be able to state that clearly enough. > > I'm slightly confused by your statement. If a consumer depends on a > > provider for a resource, how can we finish the consumer's probe without > > checking that the provider has been bound? It's true that we don't > > technically check for the device to have been bound, but the end result > > is the same. > > > > Unless I misunderstand what you're saying we'd need to have some > > mechanism to notify the consumer (after it's been probed) that the > > provider of it's resource has become available. > > You misunderstand me. Yes, I agree that your patch handles the case > where a consumer depends on a provider for a resource. But it doesn't > handle the case where one device depends on another for something other > than a resource (or perhaps for a resource that can be provided even in > the absence of a driver). Right. So to recap my original point, I do have concerns about doing the "move the device to the end of dpm_list when it is about to be probed" thing unconditionally for all devices. However, the overall idea is not bad in my view, it just needs to be refined. We first need to avoid probing for drivers during system sleep transitions, which would be good to do regardless. It also would help if we could identify the cases when the moving is really necessary and restrict it to those cases only. I'm not sure if that's practical, though. And I'm wondering if and how that is related to runtime PM? It only covers the system sleep transitions case, but who's responsible for the runtime PM part? Device drivers? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2015-09-17 04:10 +0200 |
| Message-ID | <q9wO5-5ZN-7@gated-at.bofh.it> |
| In reply to | #1226587 |
On Thu, Sep 17, 2015 at 2:27 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > On Wednesday, September 16, 2015 03:22:37 PM Alan Stern wrote: >> On Wed, 16 Sep 2015, Thierry Reding wrote: [cut] > > And I'm wondering if and how that is related to runtime PM? It only > covers the system sleep transitions case, but who's responsible for the > runtime PM part? Device drivers? > Which reminds me of something we all seem to be forgetting about: there is asynchronous suspend and resume which may cause suspend and resume callbacks of devices to be executed in an order that is different from the dpm_list order. In those cases the device that depends on another one has to explicitly wait for the other one to complete its callback in the current phase of the transition. While correct ordering of dpm_list is essential for this to work too, it by no means is sufficient, so in the end the driver having a dependency needs to know about it and act on it as needed (or we need an alternative mechanism that will do that automatically, but I'm not sure what that may be). Actually, I was thinking about adding something like pm_get() for this purpose that will do pm_runtime_get_sync() on the target and will ensure that the right things will happen during system suspend/resume in addition to that, including reordering dpm_list if necessary. Plus, of course, the complementary pm_put(). With something like that available, there should be no need to reorder dpm_list anywhere else. The problem with this approach is that the reordering becomes quite complicated then, as it would need to move the device itself after the target and anything that depends on it along with it and tracking those dependencies becomes quite problematic. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-17 19:10 +0200 |
| Message-ID | <q9KR4-1yz-37@gated-at.bofh.it> |
| In reply to | #1226626 |
On Thu, 17 Sep 2015, Rafael J. Wysocki wrote: > On Thu, Sep 17, 2015 at 2:27 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > On Wednesday, September 16, 2015 03:22:37 PM Alan Stern wrote: > >> On Wed, 16 Sep 2015, Thierry Reding wrote: > > [cut] > > > > > And I'm wondering if and how that is related to runtime PM? It only > > covers the system sleep transitions case, but who's responsible for the > > runtime PM part? Device drivers? In theory the drivers are responsible. In practice, I don't know how this is handled. > Which reminds me of something we all seem to be forgetting about: > there is asynchronous suspend and resume which may cause suspend and > resume callbacks of devices to be executed in an order that is > different from the dpm_list order. In those cases the device that > depends on another one has to explicitly wait for the other one to > complete its callback in the current phase of the transition. > > While correct ordering of dpm_list is essential for this to work too, > it by no means is sufficient, so in the end the driver having a > dependency needs to know about it and act on it as needed (or we need > an alternative mechanism that will do that automatically, but I'm not > sure what that may be). > > Actually, I was thinking about adding something like pm_get() for this > purpose that will do pm_runtime_get_sync() on the target and will > ensure that the right things will happen during system suspend/resume > in addition to that, including reordering dpm_list if necessary. > Plus, of course, the complementary pm_put(). > > With something like that available, there should be no need to reorder > dpm_list anywhere else. The problem with this approach is that the > reordering becomes quite complicated then, as it would need to move > the device itself after the target and anything that depends on it > along with it and tracking those dependencies becomes quite > problematic. Keeping explicit track of these non-child-parent dependencies seems reasonable. But I don't know how you could combine it with reordering dpm_list. One possibility might be to do a topological sort of all devices, with the initial set of constraints given by the explicit dependencies and the parent-child relations. So basically this would mean ignoring the actual dpm_list and making up a new list of your own whenever a sleep transition starts. It might work, but I'm not sure how reliable it would be. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2015-09-17 20:50 +0200 |
| Message-ID | <q9MpP-3IX-1@gated-at.bofh.it> |
| In reply to | #1227222 |
Hi Alan, On Thu, Sep 17, 2015 at 7:02 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Thu, 17 Sep 2015, Rafael J. Wysocki wrote: > >> On Thu, Sep 17, 2015 at 2:27 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: >> > On Wednesday, September 16, 2015 03:22:37 PM Alan Stern wrote: >> >> On Wed, 16 Sep 2015, Thierry Reding wrote: >> >> [cut] >> >> > >> > And I'm wondering if and how that is related to runtime PM? It only >> > covers the system sleep transitions case, but who's responsible for the >> > runtime PM part? Device drivers? > > In theory the drivers are responsible. In practice, I don't know how > this is handled. Same here, unfortunately. >> Which reminds me of something we all seem to be forgetting about: >> there is asynchronous suspend and resume which may cause suspend and >> resume callbacks of devices to be executed in an order that is >> different from the dpm_list order. In those cases the device that >> depends on another one has to explicitly wait for the other one to >> complete its callback in the current phase of the transition. >> >> While correct ordering of dpm_list is essential for this to work too, >> it by no means is sufficient, so in the end the driver having a >> dependency needs to know about it and act on it as needed (or we need >> an alternative mechanism that will do that automatically, but I'm not >> sure what that may be). Note: Problems also may happen if device A depends on device B and its driver to be present and functional and then the B's driver module is unloaded. The core doesn't prevent that from happening AFAICS. >> Actually, I was thinking about adding something like pm_get() for this >> purpose that will do pm_runtime_get_sync() on the target and will >> ensure that the right things will happen during system suspend/resume >> in addition to that, including reordering dpm_list if necessary. >> Plus, of course, the complementary pm_put(). >> >> With something like that available, there should be no need to reorder >> dpm_list anywhere else. The problem with this approach is that the >> reordering becomes quite complicated then, as it would need to move >> the device itself after the target and anything that depends on it >> along with it and tracking those dependencies becomes quite >> problematic. > > Keeping explicit track of these non-child-parent dependencies seems > reasonable. But I don't know how you could combine it with reordering > dpm_list. > > One possibility might be to do a topological sort of all devices, with > the initial set of constraints given by the explicit dependencies and > the parent-child relations. So basically this would mean ignoring the > actual dpm_list and making up a new list of your own whenever a sleep > transition starts. It might work, but I'm not sure how reliable it > would be. I'd like to go back to my initial hunch that the driver knowing about a dependency on another one should tell the core about that, so the core can make the right things happen at various times (like system suspend/resume etc). What if we introduce a mechanism allowing drivers to say "I depend on device X and its driver to be present and functional from now on" and store that information somewhere for the core to use? Some time ago (a few years ago actually IIRC) I proposed something called "PM links". The idea was to have objects representing such dependencies, although I was not taking the "the driver of the device I depend on should be present and functional going forward" condition. Say, if a driver wants to check the presence of the device+driver it needs to be functional, it will do something like ret = create_pm_link(dev, producer); and that will return -EPROBE_DEFER if the producer device is not functional. If success is returned, the link has been created and now the core will take it into account. On driver removal the core may just delete the links where the device is the "consumer". Also there may be a delete_pm_link(dev, producer) operation if needed. The creation of a link may then include the reordering of dpm_list as appropriate so all "producers" are now followed by all of their "consumers". Going forward, though, the core may use the links to make all "producers" wait for the PM callbacks of their "consumers" to complete during system suspend etc. It also may use them to prevent drivers being depended on from being unloaded and/or to force the removal of drivers that depend on something being removed. In principle it may also use those links to coordinate runtime PM transitions, but I guess that's not going to be useful in all cases, so there needs to be an opt-in mechanism for that. Please tell me what you think. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-17 23:10 +0200 |
| Message-ID | <q9OBk-78U-27@gated-at.bofh.it> |
| In reply to | #1227329 |
On Thu, 17 Sep 2015, Rafael J. Wysocki wrote: > Note: Problems also may happen if device A depends on device B and its > driver to be present and functional and then the B's driver module is > unloaded. The core doesn't prevent that from happening AFAICS. It also doesn't prevent B's driver from being unbound from the B device. To some extent the kernel _does_ prevent driver modules from being unloaded. If A's driver uses code resources provided by B's driver then the module's refcount would be larger than 0. > I'd like to go back to my initial hunch that the driver knowing about > a dependency on another one should tell the core about that, so the > core can make the right things happen at various times (like system > suspend/resume etc). > > What if we introduce a mechanism allowing drivers to say "I depend on > device X and its driver to be present and functional from now on" and > store that information somewhere for the core to use? > > Some time ago (a few years ago actually IIRC) I proposed something > called "PM links". The idea was to have objects representing such > dependencies, although I was not taking the "the driver of the device > I depend on should be present and functional going forward" condition. > > Say, if a driver wants to check the presence of the device+driver it > needs to be functional, it will do something like > > ret = create_pm_link(dev, producer); > > and that will return -EPROBE_DEFER if the producer device is not > functional. If success is returned, the link has been created and now > the core will take it into account. > > On driver removal the core may just delete the links where the device > is the "consumer". Also there may be a delete_pm_link(dev, producer) > operation if needed. > > The creation of a link may then include the reordering of dpm_list as > appropriate so all "producers" are now followed by all of their > "consumers". Going forward, though, the core may use the links to > make all "producers" wait for the PM callbacks of their "consumers" to > complete during system suspend etc. It also may use them to prevent > drivers being depended on from being unloaded and/or to force the > removal of drivers that depend on something being removed. In > principle it may also use those links to coordinate runtime PM > transitions, but I guess that's not going to be useful in all cases, > so there needs to be an opt-in mechanism for that. > > Please tell me what you think. Sounds familiar. I recall this basic approach from a Plumbers conference some years ago -- maybe that was when you first proposed it! You might want to categorize the dependencies into different types. I can think of three types offhand: The target device must be present before the current device can be probed (hard to imagine how that could be stored as a PM link if the target device isn't present, though); The target device must be bound to a driver before the current device can be probed; The target device must be at full power whenever the current device is. Maybe you can think of others. [Oddly enough, the USB subsystem has some dependencies that don't fall into any of these categories. They have to do with the peculiar way in which a low- or full-speed device is handed off from a high-speed controller to its companion low/full-speed controller, and they apply only to system resume, not to normal operation. (That is, device A requires device B to be at full power when A is being resumed from a system sleep, but not when A is operating normally or when A is being runtime-resumed.) For such things, we should keep the existing device_pm_wait_for_dev() API.] This sounds like a big change, but it might be worthwhile. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2015-09-18 02:20 +0200 |
| Message-ID | <q9Rzb-2ZL-3@gated-at.bofh.it> |
| In reply to | #1227397 |
On Thu, Sep 17, 2015 at 11:06 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Thu, 17 Sep 2015, Rafael J. Wysocki wrote: > >> Note: Problems also may happen if device A depends on device B and its >> driver to be present and functional and then the B's driver module is >> unloaded. The core doesn't prevent that from happening AFAICS. > > It also doesn't prevent B's driver from being unbound from the B > device. > > To some extent the kernel _does_ prevent driver modules from being > unloaded. If A's driver uses code resources provided by B's driver > then the module's refcount would be larger than 0. Right. >> I'd like to go back to my initial hunch that the driver knowing about >> a dependency on another one should tell the core about that, so the >> core can make the right things happen at various times (like system >> suspend/resume etc). >> >> What if we introduce a mechanism allowing drivers to say "I depend on >> device X and its driver to be present and functional from now on" and >> store that information somewhere for the core to use? >> >> Some time ago (a few years ago actually IIRC) I proposed something >> called "PM links". The idea was to have objects representing such >> dependencies, although I was not taking the "the driver of the device >> I depend on should be present and functional going forward" condition. >> >> Say, if a driver wants to check the presence of the device+driver it >> needs to be functional, it will do something like >> >> ret = create_pm_link(dev, producer); >> >> and that will return -EPROBE_DEFER if the producer device is not >> functional. If success is returned, the link has been created and now >> the core will take it into account. >> >> On driver removal the core may just delete the links where the device >> is the "consumer". Also there may be a delete_pm_link(dev, producer) >> operation if needed. >> >> The creation of a link may then include the reordering of dpm_list as >> appropriate so all "producers" are now followed by all of their >> "consumers". Going forward, though, the core may use the links to >> make all "producers" wait for the PM callbacks of their "consumers" to >> complete during system suspend etc. It also may use them to prevent >> drivers being depended on from being unloaded and/or to force the >> removal of drivers that depend on something being removed. In >> principle it may also use those links to coordinate runtime PM >> transitions, but I guess that's not going to be useful in all cases, >> so there needs to be an opt-in mechanism for that. >> >> Please tell me what you think. > > Sounds familiar. I recall this basic approach from a Plumbers > conference some years ago -- maybe that was when you first proposed it! > > You might want to categorize the dependencies into different types. I > can think of three types offhand: > > The target device must be present before the current device > can be probed (hard to imagine how that could be stored as a PM > link if the target device isn't present, though); Right, but there is a tricky part here. The presence of the device object need not imply that the device is physically present. :-) > The target device must be bound to a driver before the current > device can be probed; > > The target device must be at full power whenever the current > device is. Or even before attempting to put the current device at full power. > Maybe you can think of others. > > [Oddly enough, the USB subsystem has some dependencies that don't fall > into any of these categories. They have to do with the peculiar way in > which a low- or full-speed device is handed off from a high-speed > controller to its companion low/full-speed controller, and they apply > only to system resume, not to normal operation. (That is, device A > requires device B to be at full power when A is being resumed from a > system sleep, but not when A is operating normally or when A is being > runtime-resumed.) For such things, we should keep the existing > device_pm_wait_for_dev() API.] Absolutely. The idea is to use the existing APIs for that where it makes sense. > This sounds like a big change, but it might be worthwhile. Well, the more I think about that the more it seems to me that some redesign is needed. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Thierry Reding <thierry.reding@gmail.com> |
|---|---|
| Date | 2015-09-18 18:00 +0200 |
| Message-ID | <qa6eT-75X-47@gated-at.bofh.it> |
| In reply to | #1227329 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Sep 17, 2015 at 08:43:54PM +0200, Rafael J. Wysocki wrote: > Hi Alan, > > On Thu, Sep 17, 2015 at 7:02 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > > On Thu, 17 Sep 2015, Rafael J. Wysocki wrote: > > > >> On Thu, Sep 17, 2015 at 2:27 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > >> > On Wednesday, September 16, 2015 03:22:37 PM Alan Stern wrote: > >> >> On Wed, 16 Sep 2015, Thierry Reding wrote: > >> > >> [cut] > >> > >> > > >> > And I'm wondering if and how that is related to runtime PM? It only > >> > covers the system sleep transitions case, but who's responsible for the > >> > runtime PM part? Device drivers? > > > > In theory the drivers are responsible. In practice, I don't know how > > this is handled. > > Same here, unfortunately. > > >> Which reminds me of something we all seem to be forgetting about: > >> there is asynchronous suspend and resume which may cause suspend and > >> resume callbacks of devices to be executed in an order that is > >> different from the dpm_list order. In those cases the device that > >> depends on another one has to explicitly wait for the other one to > >> complete its callback in the current phase of the transition. > >> > >> While correct ordering of dpm_list is essential for this to work too, > >> it by no means is sufficient, so in the end the driver having a > >> dependency needs to know about it and act on it as needed (or we need > >> an alternative mechanism that will do that automatically, but I'm not > >> sure what that may be). > > Note: Problems also may happen if device A depends on device B and its > driver to be present and functional and then the B's driver module is > unloaded. The core doesn't prevent that from happening AFAICS. As Alan already mentioned this is typically solved by consumers taking a module reference. However that only makes sure that the module stays around, so references to code or global data will remain valid. However it does not prevent the device from being unbound and freeing all the resources associated with it. A lot of subsystems are buggy this way. Typically the solution here is to properly reference count objects that subsystems hand out. But that does not solve the problem entirely. You still need to deal with the situation where the device backing an object goes away. Consumers may keep a reference to the object, which ensures that the data stays around but operations on the objects would still fail (consider cases where the operation accesses registers that have been unmapped when the provider was unbound). If the core provided a means to prevent a device from being unbound if it still had consumers, that would fix a whole lot of problems at once. Of course there's still the matter of some types of devices physically disappearing (USB, PCI, ...). > >> Actually, I was thinking about adding something like pm_get() for this > >> purpose that will do pm_runtime_get_sync() on the target and will > >> ensure that the right things will happen during system suspend/resume > >> in addition to that, including reordering dpm_list if necessary. > >> Plus, of course, the complementary pm_put(). > >> > >> With something like that available, there should be no need to reorder > >> dpm_list anywhere else. The problem with this approach is that the > >> reordering becomes quite complicated then, as it would need to move > >> the device itself after the target and anything that depends on it > >> along with it and tracking those dependencies becomes quite > >> problematic. > > > > Keeping explicit track of these non-child-parent dependencies seems > > reasonable. But I don't know how you could combine it with reordering > > dpm_list. > > > > One possibility might be to do a topological sort of all devices, with > > the initial set of constraints given by the explicit dependencies and > > the parent-child relations. So basically this would mean ignoring the > > actual dpm_list and making up a new list of your own whenever a sleep > > transition starts. It might work, but I'm not sure how reliable it > > would be. > > I'd like to go back to my initial hunch that the driver knowing about > a dependency on another one should tell the core about that, so the > core can make the right things happen at various times (like system > suspend/resume etc). > > What if we introduce a mechanism allowing drivers to say "I depend on > device X and its driver to be present and functional from now on" and > store that information somewhere for the core to use? > > Some time ago (a few years ago actually IIRC) I proposed something > called "PM links". The idea was to have objects representing such > dependencies, although I was not taking the "the driver of the device > I depend on should be present and functional going forward" condition. > > Say, if a driver wants to check the presence of the device+driver it > needs to be functional, it will do something like > > ret = create_pm_link(dev, producer); > > and that will return -EPROBE_DEFER if the producer device is not > functional. If success is returned, the link has been created and now > the core will take it into account. > > On driver removal the core may just delete the links where the device > is the "consumer". Also there may be a delete_pm_link(dev, producer) > operation if needed. > > The creation of a link may then include the reordering of dpm_list as > appropriate so all "producers" are now followed by all of their > "consumers". Going forward, though, the core may use the links to > make all "producers" wait for the PM callbacks of their "consumers" to > complete during system suspend etc. It also may use them to prevent > drivers being depended on from being unloaded and/or to force the > removal of drivers that depend on something being removed. In > principle it may also use those links to coordinate runtime PM > transitions, but I guess that's not going to be useful in all cases, > so there needs to be an opt-in mechanism for that. Force-removing drivers that depend on a device that's being unbound would be a possibility to solve the problem where consumers depend on a device that could physically go away. It might also be the right thing to do in any case. Presumably somebody unloading a module want to do just that, and refusing to do so isn't playing very nice. Of course allowing random modules to be removed even if a lot of consumers might depend on it may not be friendly either. Consider if you unload a GPIO driver that provides a pin that's used to enable power to an eMMC that might have the root filesystem. Then again, if you unload a module you better know what you're doing anyway, so maybe that's not something we need to be concerned about. > Please tell me what you think. I think that's a great idea. There's probably some bikeshedding to be had, but on the whole I think this would add very useful information to the driver model. Many subsystems nowadays already provide a very similar API, often of the form: resource = [dev_]*_get(dev, "name"); Subsystems usually use dev and "name" to look up the provider and the resource. When they do lookup the provider they will typically be able to get at the underlying struct device, so this would provide a very nice entrypoint to call the core function. That way we can move this into subsystems and individual drivers don't have to be updated. I think this would also tie in nicely with Tomeu's patch set to do on-demand probing. Essentially a [dev_]*_get() call could in turn call this new "declare dependency" API, and the new API could underneath do on-demand probing. Given that this isn't a strictly PM mechanism anymore, perhaps something like: int device_depend(struct device *dev, struct device *target); would be a more generic option. Thierry
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2015-09-19 01:10 +0200 |
| Message-ID | <qacWZ-iz-7@gated-at.bofh.it> |
| In reply to | #1228111 |
Hi Thierry, On Fri, Sep 18, 2015 at 5:55 PM, Thierry Reding <thierry.reding@gmail.com> wrote: > On Thu, Sep 17, 2015 at 08:43:54PM +0200, Rafael J. Wysocki wrote: >> Hi Alan, >> >> On Thu, Sep 17, 2015 at 7:02 PM, Alan Stern <stern@rowland.harvard.edu> wrote: >> > On Thu, 17 Sep 2015, Rafael J. Wysocki wrote: >> > >> >> On Thu, Sep 17, 2015 at 2:27 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: >> >> > On Wednesday, September 16, 2015 03:22:37 PM Alan Stern wrote: >> >> >> On Wed, 16 Sep 2015, Thierry Reding wrote: >> >> >> >> [cut] >> >> >> >> > >> >> > And I'm wondering if and how that is related to runtime PM? It only >> >> > covers the system sleep transitions case, but who's responsible for the >> >> > runtime PM part? Device drivers? >> > >> > In theory the drivers are responsible. In practice, I don't know how >> > this is handled. >> >> Same here, unfortunately. >> >> >> Which reminds me of something we all seem to be forgetting about: >> >> there is asynchronous suspend and resume which may cause suspend and >> >> resume callbacks of devices to be executed in an order that is >> >> different from the dpm_list order. In those cases the device that >> >> depends on another one has to explicitly wait for the other one to >> >> complete its callback in the current phase of the transition. >> >> >> >> While correct ordering of dpm_list is essential for this to work too, >> >> it by no means is sufficient, so in the end the driver having a >> >> dependency needs to know about it and act on it as needed (or we need >> >> an alternative mechanism that will do that automatically, but I'm not >> >> sure what that may be). >> >> Note: Problems also may happen if device A depends on device B and its >> driver to be present and functional and then the B's driver module is >> unloaded. The core doesn't prevent that from happening AFAICS. > > As Alan already mentioned this is typically solved by consumers taking a > module reference. However that only makes sure that the module stays > around, so references to code or global data will remain valid. However > it does not prevent the device from being unbound and freeing all the > resources associated with it. > > A lot of subsystems are buggy this way. Typically the solution here is > to properly reference count objects that subsystems hand out. But that > does not solve the problem entirely. You still need to deal with the > situation where the device backing an object goes away. Consumers may > keep a reference to the object, which ensures that the data stays around > but operations on the objects would still fail (consider cases where the > operation accesses registers that have been unmapped when the provider > was unbound). > > If the core provided a means to prevent a device from being unbound if > it still had consumers, that would fix a whole lot of problems at once. Indeed. > Of course there's still the matter of some types of devices physically > disappearing (USB, PCI, ...). Right. In some cases removal is simply necessary as part of the cleanup, like after a surprise hot-unplug of a device, for example. In those cases everything that depended on the device that went away should be unbound from drivers at least IMO. >> >> Actually, I was thinking about adding something like pm_get() for this >> >> purpose that will do pm_runtime_get_sync() on the target and will >> >> ensure that the right things will happen during system suspend/resume >> >> in addition to that, including reordering dpm_list if necessary. >> >> Plus, of course, the complementary pm_put(). >> >> >> >> With something like that available, there should be no need to reorder >> >> dpm_list anywhere else. The problem with this approach is that the >> >> reordering becomes quite complicated then, as it would need to move >> >> the device itself after the target and anything that depends on it >> >> along with it and tracking those dependencies becomes quite >> >> problematic. >> > >> > Keeping explicit track of these non-child-parent dependencies seems >> > reasonable. But I don't know how you could combine it with reordering >> > dpm_list. >> > >> > One possibility might be to do a topological sort of all devices, with >> > the initial set of constraints given by the explicit dependencies and >> > the parent-child relations. So basically this would mean ignoring the >> > actual dpm_list and making up a new list of your own whenever a sleep >> > transition starts. It might work, but I'm not sure how reliable it >> > would be. >> >> I'd like to go back to my initial hunch that the driver knowing about >> a dependency on another one should tell the core about that, so the >> core can make the right things happen at various times (like system >> suspend/resume etc). >> >> What if we introduce a mechanism allowing drivers to say "I depend on >> device X and its driver to be present and functional from now on" and >> store that information somewhere for the core to use? >> >> Some time ago (a few years ago actually IIRC) I proposed something >> called "PM links". The idea was to have objects representing such >> dependencies, although I was not taking the "the driver of the device >> I depend on should be present and functional going forward" condition. >> >> Say, if a driver wants to check the presence of the device+driver it >> needs to be functional, it will do something like >> >> ret = create_pm_link(dev, producer); >> >> and that will return -EPROBE_DEFER if the producer device is not >> functional. If success is returned, the link has been created and now >> the core will take it into account. >> >> On driver removal the core may just delete the links where the device >> is the "consumer". Also there may be a delete_pm_link(dev, producer) >> operation if needed. >> >> The creation of a link may then include the reordering of dpm_list as >> appropriate so all "producers" are now followed by all of their >> "consumers". Going forward, though, the core may use the links to >> make all "producers" wait for the PM callbacks of their "consumers" to >> complete during system suspend etc. It also may use them to prevent >> drivers being depended on from being unloaded and/or to force the >> removal of drivers that depend on something being removed. In >> principle it may also use those links to coordinate runtime PM >> transitions, but I guess that's not going to be useful in all cases, >> so there needs to be an opt-in mechanism for that. > > Force-removing drivers that depend on a device that's being unbound > would be a possibility to solve the problem where consumers depend on a > device that could physically go away. It might also be the right thing > to do in any case. Presumably somebody unloading a module want to do > just that, and refusing to do so isn't playing very nice. Of course > allowing random modules to be removed even if a lot of consumers might > depend on it may not be friendly either. Consider if you unload a GPIO > driver that provides a pin that's used to enable power to an eMMC that > might have the root filesystem. > > Then again, if you unload a module you better know what you're doing > anyway, so maybe that's not something we need to be concerned about. I think that it's better to fail module unloads in such cases by default (to prevent simple silly mistakes from having possibly severe consequences), but if a "force" option is used, we should regard that as "the user really means it" and do as requested. That would be very much analogous to the hot-unplug situation from the software perspective. >> Please tell me what you think. > > I think that's a great idea. There's probably some bikeshedding to be > had, but on the whole I think this would add very useful information to > the driver model. > > Many subsystems nowadays already provide a very similar API, often of > the form: > > resource = [dev_]*_get(dev, "name"); > > Subsystems usually use dev and "name" to look up the provider and the > resource. When they do lookup the provider they will typically be able > to get at the underlying struct device, so this would provide a very > nice entrypoint to call the core function. That way we can move this > into subsystems and individual drivers don't have to be updated. Right. > I think this would also tie in nicely with Tomeu's patch set to do > on-demand probing. Essentially a [dev_]*_get() call could in turn call > this new "declare dependency" API, and the new API could underneath do > on-demand probing. > > Given that this isn't a strictly PM mechanism anymore, perhaps something > like: > > int device_depend(struct device *dev, struct device *target); > > would be a more generic option. I thought about something like link_device(dev, target, flags), where the last argument would indicate what the core is supposed to use the link for (removal handling, system suspend/resume, runtime PM etc). And I agree that this isn't really PM-specific. OK, thanks a lot for the feedback! Let me think about that a bit more and I'll try to come up with a more detailed design description. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Thierry Reding <thierry.reding@gmail.com> |
|---|---|
| Date | 2015-09-21 11:00 +0200 |
| Message-ID | <qb573-1Iu-3@gated-at.bofh.it> |
| In reply to | #1228338 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, Sep 19, 2015 at 01:07:56AM +0200, Rafael J. Wysocki wrote: > On Fri, Sep 18, 2015 at 5:55 PM, Thierry Reding <thierry.reding@gmail.com> wrote: [...] > > Of course there's still the matter of some types of devices physically > > disappearing (USB, PCI, ...). > > Right. In some cases removal is simply necessary as part of the > cleanup, like after a surprise hot-unplug of a device, for example. > In those cases everything that depended on the device that went away > should be unbound from drivers at least IMO. Agreed. > > Force-removing drivers that depend on a device that's being unbound > > would be a possibility to solve the problem where consumers depend on a > > device that could physically go away. It might also be the right thing > > to do in any case. Presumably somebody unloading a module want to do > > just that, and refusing to do so isn't playing very nice. Of course > > allowing random modules to be removed even if a lot of consumers might > > depend on it may not be friendly either. Consider if you unload a GPIO > > driver that provides a pin that's used to enable power to an eMMC that > > might have the root filesystem. > > > > Then again, if you unload a module you better know what you're doing > > anyway, so maybe that's not something we need to be concerned about. > > I think that it's better to fail module unloads in such cases by > default (to prevent simple silly mistakes from having possibly severe > consequences), but if a "force" option is used, we should regard that > as "the user really means it" and do as requested. That would be very > much analogous to the hot-unplug situation from the software > perspective. Sounds very reasonable to me. > > I think this would also tie in nicely with Tomeu's patch set to do > > on-demand probing. Essentially a [dev_]*_get() call could in turn call > > this new "declare dependency" API, and the new API could underneath do > > on-demand probing. > > > > Given that this isn't a strictly PM mechanism anymore, perhaps something > > like: > > > > int device_depend(struct device *dev, struct device *target); > > > > would be a more generic option. > > I thought about something like link_device(dev, target, flags), where > the last argument would indicate what the core is supposed to use the > link for (removal handling, system suspend/resume, runtime PM etc). Sounds good to me. I think the core isn't quite consistent on the naming of functions, so we have things like device_register/unregister() versus get/put_device(). I'd lean towards device_link(dev, target, flags), but I'll go with any color you'd like the shed to have. > And I agree that this isn't really PM-specific. > > OK, thanks a lot for the feedback! > > Let me think about that a bit more and I'll try to come up with a more > detailed design description. This sounds like it's not going to make it into v4.3 anymore, so I'll need to think about the easiest way to (temporarily) fix up the current regression. Is this something that you will have time to implement yourself? If so, please keep me in the loop and Cc me on any patches that you need tested. If you're short on time, let me know as well and I'll see if I can take a stab at it myself, though I'm pretty sure I'll need further guidance along the way. Thierry
[toc] | [prev] | [next] | [standalone]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-21 16:40 +0200 |
| Message-ID | <qbaq5-Zi-1@gated-at.bofh.it> |
| In reply to | #1229127 |
On Mon, 21 Sep 2015, Thierry Reding wrote: > > > Force-removing drivers that depend on a device that's being unbound > > > would be a possibility to solve the problem where consumers depend on a > > > device that could physically go away. It might also be the right thing > > > to do in any case. Presumably somebody unloading a module want to do > > > just that, and refusing to do so isn't playing very nice. Of course > > > allowing random modules to be removed even if a lot of consumers might > > > depend on it may not be friendly either. Consider if you unload a GPIO > > > driver that provides a pin that's used to enable power to an eMMC that > > > might have the root filesystem. > > > > > > Then again, if you unload a module you better know what you're doing > > > anyway, so maybe that's not something we need to be concerned about. > > > > I think that it's better to fail module unloads in such cases by > > default (to prevent simple silly mistakes from having possibly severe > > consequences), but if a "force" option is used, we should regard that > > as "the user really means it" and do as requested. That would be very > > much analogous to the hot-unplug situation from the software > > perspective. > > Sounds very reasonable to me. I'm not so sure about this. For one thing, how are you going to distinguish which module unloads are safe? For another, even if you do make this distinction, don't you think people will get into the habit of always using the "force" option? My impression is that most module unloads end up causing some device to be unbound from a driver, or even completely deregistered. Right now the kernel uses the "You better know what you're doing when you unload a module" point of view, and I don't see any good reasons for changing. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-09-22 02:00 +0200 |
| Message-ID | <qbja2-57d-13@gated-at.bofh.it> |
| In reply to | #1229429 |
On Monday, September 21, 2015 10:34:54 AM Alan Stern wrote: > On Mon, 21 Sep 2015, Thierry Reding wrote: > > > > > Force-removing drivers that depend on a device that's being unbound > > > > would be a possibility to solve the problem where consumers depend on a > > > > device that could physically go away. It might also be the right thing > > > > to do in any case. Presumably somebody unloading a module want to do > > > > just that, and refusing to do so isn't playing very nice. Of course > > > > allowing random modules to be removed even if a lot of consumers might > > > > depend on it may not be friendly either. Consider if you unload a GPIO > > > > driver that provides a pin that's used to enable power to an eMMC that > > > > might have the root filesystem. > > > > > > > > Then again, if you unload a module you better know what you're doing > > > > anyway, so maybe that's not something we need to be concerned about. > > > > > > I think that it's better to fail module unloads in such cases by > > > default (to prevent simple silly mistakes from having possibly severe > > > consequences), but if a "force" option is used, we should regard that > > > as "the user really means it" and do as requested. That would be very > > > much analogous to the hot-unplug situation from the software > > > perspective. > > > > Sounds very reasonable to me. > > I'm not so sure about this. For one thing, how are you going to > distinguish which module unloads are safe? Ones that have no dependencies? Very simple: If the driver being unloaded is explicitly depended on by something (ie. there is a "device link" to it), we fail the unload with -EBUSY unless the "force" option is used. > For another, even if you do make this distinction, don't you think > people will get into the habit of always using the "force" option? My > impression is that most module unloads end up causing some device to be > unbound from a driver, or even completely deregistered. > > Right now the kernel uses the "You better know what you're doing when > you unload a module" point of view, and I don't see any good reasons > for changing. Well, is that point of view appropriate from the users' perspective? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-22 03:30 +0200 |
| Message-ID | <qbkz8-7dx-3@gated-at.bofh.it> |
| In reply to | #1229843 |
On Tue, 22 Sep 2015, Rafael J. Wysocki wrote: > On Monday, September 21, 2015 10:34:54 AM Alan Stern wrote: > > On Mon, 21 Sep 2015, Thierry Reding wrote: > > > > > > > Force-removing drivers that depend on a device that's being unbound > > > > > would be a possibility to solve the problem where consumers depend on a > > > > > device that could physically go away. It might also be the right thing > > > > > to do in any case. Presumably somebody unloading a module want to do > > > > > just that, and refusing to do so isn't playing very nice. Of course > > > > > allowing random modules to be removed even if a lot of consumers might > > > > > depend on it may not be friendly either. Consider if you unload a GPIO > > > > > driver that provides a pin that's used to enable power to an eMMC that > > > > > might have the root filesystem. > > > > > > > > > > Then again, if you unload a module you better know what you're doing > > > > > anyway, so maybe that's not something we need to be concerned about. > > > > > > > > I think that it's better to fail module unloads in such cases by > > > > default (to prevent simple silly mistakes from having possibly severe > > > > consequences), but if a "force" option is used, we should regard that > > > > as "the user really means it" and do as requested. That would be very > > > > much analogous to the hot-unplug situation from the software > > > > perspective. > > > > > > Sounds very reasonable to me. > > > > I'm not so sure about this. For one thing, how are you going to > > distinguish which module unloads are safe? > > Ones that have no dependencies? Does a parent-child relationship count as a dependency? AFAIK, that's the only sort of dependency we have for mounted filesystems, in general. > Very simple: If the driver being unloaded is explicitly depended on by > something (ie. there is a "device link" to it), we fail the unload with > -EBUSY unless the "force" option is used. Hmmm. In other words, you will iterate through all the drivers, checking the ->owner field against the module being removed. Then for each matching driver, you will iterate through all the bound devices, and all their descendants, looking for links of the appropriate type. And perhaps do the same thing for subsystems and classes. Doable, I guess, even if it is inelegant. Fortunately module unload has no timing requirements. > > For another, even if you do make this distinction, don't you think > > people will get into the habit of always using the "force" option? My > > impression is that most module unloads end up causing some device to be > > unbound from a driver, or even completely deregistered. > > > > Right now the kernel uses the "You better know what you're doing when > > you unload a module" point of view, and I don't see any good reasons > > for changing. > > Well, is that point of view appropriate from the users' perspective? I suspect people will find it more appropriate than the new point of view you are proposing. I don't know how often people unload modules, but I suspect almost every time they do, it involves unregistering one or more devices. Goodness knows how many of those devices will be the target of a dependency link, though. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2015-09-22 02:40 +0200 |
| Message-ID | <qbjMK-64I-3@gated-at.bofh.it> |
| In reply to | #1229127 |
Hi, On Mon, Sep 21, 2015 at 10:51 AM, Thierry Reding <thierry.reding@gmail.com> wrote: > On Sat, Sep 19, 2015 at 01:07:56AM +0200, Rafael J. Wysocki wrote: >> On Fri, Sep 18, 2015 at 5:55 PM, Thierry Reding <thierry.reding@gmail.com> wrote: > [...] >> > Of course there's still the matter of some types of devices physically >> > disappearing (USB, PCI, ...). >> >> Right. In some cases removal is simply necessary as part of the >> cleanup, like after a surprise hot-unplug of a device, for example. >> In those cases everything that depended on the device that went away >> should be unbound from drivers at least IMO. > > Agreed. > >> > Force-removing drivers that depend on a device that's being unbound >> > would be a possibility to solve the problem where consumers depend on a >> > device that could physically go away. It might also be the right thing >> > to do in any case. Presumably somebody unloading a module want to do >> > just that, and refusing to do so isn't playing very nice. Of course >> > allowing random modules to be removed even if a lot of consumers might >> > depend on it may not be friendly either. Consider if you unload a GPIO >> > driver that provides a pin that's used to enable power to an eMMC that >> > might have the root filesystem. >> > >> > Then again, if you unload a module you better know what you're doing >> > anyway, so maybe that's not something we need to be concerned about. >> >> I think that it's better to fail module unloads in such cases by >> default (to prevent simple silly mistakes from having possibly severe >> consequences), but if a "force" option is used, we should regard that >> as "the user really means it" and do as requested. That would be very >> much analogous to the hot-unplug situation from the software >> perspective. > > Sounds very reasonable to me. > >> > I think this would also tie in nicely with Tomeu's patch set to do >> > on-demand probing. Essentially a [dev_]*_get() call could in turn call >> > this new "declare dependency" API, and the new API could underneath do >> > on-demand probing. >> > >> > Given that this isn't a strictly PM mechanism anymore, perhaps something >> > like: >> > >> > int device_depend(struct device *dev, struct device *target); >> > >> > would be a more generic option. >> >> I thought about something like link_device(dev, target, flags), where >> the last argument would indicate what the core is supposed to use the >> link for (removal handling, system suspend/resume, runtime PM etc). > > Sounds good to me. I think the core isn't quite consistent on the naming > of functions, so we have things like device_register/unregister() versus > get/put_device(). I'd lean towards device_link(dev, target, flags), but > I'll go with any color you'd like the shed to have. Well, whatever. n any case it would be good to have "link" and "device" in the name, regardless of the ordering. :-) >> And I agree that this isn't really PM-specific. >> >> OK, thanks a lot for the feedback! >> >> Let me think about that a bit more and I'll try to come up with a more >> detailed design description. > > This sounds like it's not going to make it into v4.3 anymore, so I'll > need to think about the easiest way to (temporarily) fix up the current > regression. > > Is this something that you will have time to implement yourself? If so, > please keep me in the loop and Cc me on any patches that you need > tested. If you're short on time, let me know as well and I'll see if I > can take a stab at it myself, though I'm pretty sure I'll need further > guidance along the way. I'd like to try to do that myself, but that'll take some time. I hope this isn't a problem. Given the time frame it should be doable for v4.4 in theory. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Tomeu Vizoso <tomeu.vizoso@collabora.com> |
|---|---|
| Date | 2015-09-17 07:50 +0200 |
| Message-ID | <q9Af0-2yn-21@gated-at.bofh.it> |
| In reply to | #1226587 |
On 17 September 2015 at 02:27, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > On Wednesday, September 16, 2015 03:22:37 PM Alan Stern wrote: >> >> It would also help if your patch checked to see if the device has any >> children, and avoided moving it to the end of the list if it does. In >> fact, that might be sufficient to avoid almost all problems. > > I agree. > > In any case if a device that already has children is about to be probed, > this is sort of a corner case anyway and should be handled as such. Just wanted to mention that it's very common in platforms that make use of DT to have some devices registered before their parents have probed. If I grep for DTS with simple-bus and simple-mfd I get 802 matches. Regards, Tomeu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2015-09-17 20:20 +0200 |
| Message-ID | <q9LWP-38s-27@gated-at.bofh.it> |
| In reply to | #1226681 |
Hi, On Thu, Sep 17, 2015 at 7:40 AM, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote: > On 17 September 2015 at 02:27, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: >> On Wednesday, September 16, 2015 03:22:37 PM Alan Stern wrote: >>> >>> It would also help if your patch checked to see if the device has any >>> children, and avoided moving it to the end of the list if it does. In >>> fact, that might be sufficient to avoid almost all problems. >> >> I agree. >> >> In any case if a device that already has children is about to be probed, >> this is sort of a corner case anyway and should be handled as such. > > Just wanted to mention that it's very common in platforms that make > use of DT to have some devices registered before their parents have probed. > If I grep for DTS with simple-bus and simple-mfd I get 802 matches. This is good to know, thanks! Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-09-17 21:30 +0200 |
| Message-ID | <q9N2z-4KB-21@gated-at.bofh.it> |
| In reply to | #1227285 |
On Thu, 17 Sep 2015, Rafael J. Wysocki wrote: > Hi, > > On Thu, Sep 17, 2015 at 7:40 AM, Tomeu Vizoso > <tomeu.vizoso@collabora.com> wrote: > > On 17 September 2015 at 02:27, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > >> On Wednesday, September 16, 2015 03:22:37 PM Alan Stern wrote: > >>> > >>> It would also help if your patch checked to see if the device has any > >>> children, and avoided moving it to the end of the list if it does. In > >>> fact, that might be sufficient to avoid almost all problems. > >> > >> I agree. > >> > >> In any case if a device that already has children is about to be probed, > >> this is sort of a corner case anyway and should be handled as such. > > > > Just wanted to mention that it's very common in platforms that make > > use of DT to have some devices registered before their parents have probed. > > If I grep for DTS with simple-bus and simple-mfd I get 802 matches. > > > This is good to know, thanks! Hmmm. In view of this, maybe it's not worthwhile to try looking for such things. Given that they exist all over the place, we will definitely need to handle them correctly. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | linux.kernel
csiph-web