Hi,
On Fri, Jul 1, 2011 at 8:33 AM, Rafael J. Wysocki r...@sisk.pl wrote:
In theory it is possible that a subsystem (e.g. bus type) will enable
runtime PM for devices without drivers and will (for example) put them
into low power states until the drivers are loaded. Then, it makes
sense for
On Thu, 30 Jun 2011, Kevin Hilman wrote:
Another curiosity is that, contrary to the above documentation, there is
no usage_count increment before the bus/driver -remove() (although
there is a _get_sync/_put_sync around the sysfs_remove and notifier just
before the bus/driver-remove().
I
Ohad Ben-Cohen o...@wizery.com writes:
On Fri, Jul 1, 2011 at 3:33 AM, Rafael J. Wysocki r...@sisk.pl wrote:
In theory it is possible that a subsystem (e.g. bus type) will enable
runtime PM for devices without drivers and will (for example) put them
into low power states until the drivers are
On Thu, 30 Jun 2011, Kevin Hilman wrote:
I'm still confused about the usage_count increment around -probe
though.
As a few people have already pointed out, some subsystems do perform
runtime PM on driverless devices.
The basic idea is simple: We don't want any PM callbacks to race with
each
On Fri, 1 Jul 2011, Kevin Hilman wrote:
OK, so the -probe() part has been explained and makes sense, but I
would expect -remove() to be similarily protected (as the documentation
states.) But that is not the case. Is that a bug? If so, patch below
makes the code match the documentation.
I
Alan Stern st...@rowland.harvard.edu writes:
On Fri, 1 Jul 2011, Kevin Hilman wrote:
OK, so the -probe() part has been explained and makes sense, but I
would expect -remove() to be similarily protected (as the documentation
states.) But that is not the case. Is that a bug? If so, patch
On Fri, 1 Jul 2011, Kevin Hilman wrote:
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -329,13 +329,13 @@ static void __device_release_driver(struct device
*dev)
blocking_notifier_call_chain(dev-bus-p-bus_notifier,
Alan Stern st...@rowland.harvard.edu writes:
On Fri, 1 Jul 2011, Kevin Hilman wrote:
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -329,13 +329,13 @@ static void __device_release_driver(struct device
*dev)
blocking_notifier_call_chain(dev-bus-p-bus_notifier,
Hi,
On Friday, July 01, 2011, Kevin Hilman wrote:
Alan Stern st...@rowland.harvard.edu writes:
On Fri, 1 Jul 2011, Kevin Hilman wrote:
OK, so the -probe() part has been explained and makes sense, but I
would expect -remove() to be similarily protected (as the documentation
states.)
On Fri, 1 Jul 2011, Rafael J. Wysocki wrote:
Hi,
On Friday, July 01, 2011, Kevin Hilman wrote:
Alan Stern st...@rowland.harvard.edu writes:
On Fri, 1 Jul 2011, Kevin Hilman wrote:
OK, so the -probe() part has been explained and makes sense, but I
would expect -remove() to be
On Friday, July 01, 2011, Kevin Hilman wrote:
Continuing on the theme of runtime PM interactions with other parts of
the driver core...
In drivers/base/dd.c:driver_probe_device(), the driver core increments
the usage count around -probe():
[...]
On Friday, July 01, 2011, Alan Stern wrote:
On Fri, 1 Jul 2011, Rafael J. Wysocki wrote:
Hi,
On Friday, July 01, 2011, Kevin Hilman wrote:
Alan Stern st...@rowland.harvard.edu writes:
On Fri, 1 Jul 2011, Kevin Hilman wrote:
OK, so the -probe() part has been explained
On Friday, July 01, 2011, Kevin Hilman wrote:
Kevin Hilman khil...@ti.com writes:
Continuing on the theme of runtime PM interactions with other parts of
the driver core...
In drivers/base/dd.c:driver_probe_device(), the driver core increments
the usage count around -probe():
On Fri, Jul 1, 2011 at 3:33 AM, Rafael J. Wysocki r...@sisk.pl wrote:
In theory it is possible that a subsystem (e.g. bus type) will enable
runtime PM for devices without drivers and will (for example) put them
into low power states until the drivers are loaded. Then, it makes
sense for the
14 matches
Mail list logo
