On Thu, 25 Aug 2005, Todd Poynor wrote:
> In case it's getting lost in all these details, the main point of all
> this is to pose the question: "are arbitrary power parameters arranged
> into a set with mutually consistent values (called here an operating
> point) a good low-level abstraction
On Thu, 25 Aug 2005, Todd Poynor wrote:
In case it's getting lost in all these details, the main point of all
this is to pose the question: are arbitrary power parameters arranged
into a set with mutually consistent values (called here an operating
point) a good low-level abstraction for
On Mon, 8 Aug 2005, Todd Poynor wrote:
> PowerOP is a system power parameter management API submitted for
> discussion. PowerOP writes and reads power "operating points",
> comprised of arbitrary integer-valued values, called power parameters,
> that correspond to registers, clocks, dividers,
On Mon, 8 Aug 2005, Todd Poynor wrote:
PowerOP is a system power parameter management API submitted for
discussion. PowerOP writes and reads power operating points,
comprised of arbitrary integer-valued values, called power parameters,
that correspond to registers, clocks, dividers, voltage
On Fri, 5 Aug 2005, Nigel Cunningham wrote:
> Hi.
>
> I finally found some time to finish this off. I don't really like the
> end result - the macros looked clearer to me - but here goes. If it
> looks okay, I'll seek sign offs from each of the affected driver
> maintainers and from Ingo. Anyone
On Fri, 5 Aug 2005, Nigel Cunningham wrote:
Hi.
I finally found some time to finish this off. I don't really like the
end result - the macros looked clearer to me - but here goes. If it
looks okay, I'll seek sign offs from each of the affected driver
maintainers and from Ingo. Anyone else?
On Sat, 30 Jul 2005, Dominik Brodowski wrote:
> dpm_runtime_suspend and _resume() would be quite useful for some PCMCIA
> tasks. However, they are only exported in drivers/base/power/power.h. Any
> objection to moving it to include/linux/pm.h ? Any plans to break the
> functionality these
On Sat, 30 Jul 2005, Dominik Brodowski wrote:
dpm_runtime_suspend and _resume() would be quite useful for some PCMCIA
tasks. However, they are only exported in drivers/base/power/power.h. Any
objection to moving it to include/linux/pm.h ? Any plans to break the
functionality these functions
On Thu, 21 Jul 2005, Nigel Cunningham wrote:
> This patch implements a new PF_SYNCTHREAD flag, which allows upcoming
> the refrigerator implementation to know that a thread is syncing data to
> disk. This allows the refrigerator to be more reliable, even under heavy
> load, because it can
On Thu, 21 Jul 2005, Nigel Cunningham wrote:
> This patch implements freezer support for workqueues. The current
> refrigerator implementation makes all workqueues NOFREEZE, regardless of
> whether they need to be or not.
A few comments..
> Signed-off by: Nigel Cunningham <[EMAIL PROTECTED]>
On Thu, 21 Jul 2005, Nigel Cunningham wrote:
This patch implements freezer support for workqueues. The current
refrigerator implementation makes all workqueues NOFREEZE, regardless of
whether they need to be or not.
A few comments..
Signed-off by: Nigel Cunningham [EMAIL PROTECTED]
On Thu, 21 Jul 2005, Nigel Cunningham wrote:
This patch implements a new PF_SYNCTHREAD flag, which allows upcoming
the refrigerator implementation to know that a thread is syncing data to
disk. This allows the refrigerator to be more reliable, even under heavy
load, because it can separate
On Wed, 6 Apr 2005, Alan Stern wrote:
> The patch looks good. But isn't there still a problem with
> device_release_driver()? It doesn't wait for the klist_node to be removed
> from the klist before unlocking the device and moving on. As a result, if
> another driver was waiting to bind to
On Wed, 6 Apr 2005, Alan Stern wrote:
The patch looks good. But isn't there still a problem with
device_release_driver()? It doesn't wait for the klist_node to be removed
from the klist before unlocking the device and moving on. As a result, if
another driver was waiting to bind to the
Sorry about the delay in responding, there were some bugs to attend to,
some of which you may have inadvertantly caught below.
On Sat, 2 Apr 2005, Alan Stern wrote:
> I looked through the new driver model code a bit more. There appears to
> be a few problems (unless I'm using out-of-date
Sorry about the delay in responding, there were some bugs to attend to,
some of which you may have inadvertantly caught below.
On Sat, 2 Apr 2005, Alan Stern wrote:
I looked through the new driver model code a bit more. There appears to
be a few problems (unless I'm using out-of-date code).
On Thu, 31 Mar 2005, David Brownell wrote:
> On Thursday 31 March 2005 10:26 am, Patrick Mochel wrote:
> > Conversely, we only want to automatically suspend the device, or allow the
> > device to be explicitly put to sleep, if the device is not being used.
>
> And be a
On Thu, 31 Mar 2005, David Brownell wrote:
> On Thursday 31 March 2005 9:59 am, Patrick Mochel wrote:
> > On Thu, 31 Mar 2005, Alan Stern wrote:
> > > On Wed, 30 Mar 2005, Patrick Mochel wrote:
> >
> > > > In fact, we probably want to add a c
On Thu, 31 Mar 2005, Greg KH wrote:
> Andrew pointed out to me that the new driver core code spewes a lot of
> stuff in the syslog for every device it tries to match up with a driver
> (if you look closely, it seems that the if check in __device_attach()
> will never not trigger...)
>
>
On Thu, 31 Mar 2005, Alan Stern wrote:
> On Wed, 30 Mar 2005, Patrick Mochel wrote:
>
> > > Having thought it through, I believe all we need for USB support is this:
> > >
> > > Whenever usb_register() in the USB core calls driver_register()
> > >
On Thu, 31 Mar 2005, Alan Stern wrote:
> On Wed, 30 Mar 2005, Patrick Mochel wrote:
> > In fact, we probably want to add a counter to every device for all "open
> > connections" so the device doesn't try to automatically sleep while a
> > device node is open.
On Thu, 31 Mar 2005, Dmitry Torokhov wrote:
> Ok, what do you think about this one?
>
> ===
>
> swsusp: disable usermodehelper after generating memory snapshot and
> before resuming devices, so when device fails to resume we
On Thu, 31 Mar 2005, Dmitry Torokhov wrote:
Ok, what do you think about this one?
===
swsusp: disable usermodehelper after generating memory snapshot and
before resuming devices, so when device fails to resume we
On Thu, 31 Mar 2005, Alan Stern wrote:
On Wed, 30 Mar 2005, Patrick Mochel wrote:
In fact, we probably want to add a counter to every device for all open
connections so the device doesn't try to automatically sleep while a
device node is open. Once it reaches 0, we can have it enter
On Thu, 31 Mar 2005, Alan Stern wrote:
On Wed, 30 Mar 2005, Patrick Mochel wrote:
Having thought it through, I believe all we need for USB support is this:
Whenever usb_register() in the USB core calls driver_register()
and the call filters down to driver_attach(), that routine
On Thu, 31 Mar 2005, Greg KH wrote:
Andrew pointed out to me that the new driver core code spewes a lot of
stuff in the syslog for every device it tries to match up with a driver
(if you look closely, it seems that the if check in __device_attach()
will never not trigger...)
Everything
On Thu, 31 Mar 2005, David Brownell wrote:
On Thursday 31 March 2005 9:59 am, Patrick Mochel wrote:
On Thu, 31 Mar 2005, Alan Stern wrote:
On Wed, 30 Mar 2005, Patrick Mochel wrote:
In fact, we probably want to add a counter to every device for all open
connections so the device
On Thu, 31 Mar 2005, David Brownell wrote:
On Thursday 31 March 2005 10:26 am, Patrick Mochel wrote:
Conversely, we only want to automatically suspend the device, or allow the
device to be explicitly put to sleep, if the device is not being used.
And be able to suspend itself, even
On Wed, 30 Mar 2005, Dmitry Torokhov wrote:
> Will the lock be exported (via helper functions)? I always felt dirty using
> subsys.rwsem because it I think it was supposed to be implementation detail.
Sure, why not? See the attached patch for helpers, exported GPL only of
course.
Thanks,
On Tue, 29 Mar 2005, Alan Stern wrote:
> On Mon, 28 Mar 2005, Patrick Mochel wrote:
>
> > How is this related to (8) above? Do you need some sort of protected,
> > short path through the core to add the device, but not bind it or add it
> > to the PM core?
>
>
On Mon, 28 Mar 2005, Alan Stern wrote:
> > For now, I'm willing to punt on those and consider them subsystem-specific
> > until more is known about those situations' characteristics. As it
> > currently stands, the core will not lock more than 1 device at a time.
>
> That's absolutely not true.
On Mon, 28 Mar 2005, Alan Stern wrote:
For now, I'm willing to punt on those and consider them subsystem-specific
until more is known about those situations' characteristics. As it
currently stands, the core will not lock more than 1 device at a time.
That's absolutely not true.
On Tue, 29 Mar 2005, Alan Stern wrote:
On Mon, 28 Mar 2005, Patrick Mochel wrote:
How is this related to (8) above? Do you need some sort of protected,
short path through the core to add the device, but not bind it or add it
to the PM core?
Having thought it through, I believe all we
On Wed, 30 Mar 2005, Dmitry Torokhov wrote:
Will the lock be exported (via helper functions)? I always felt dirty using
subsys.rwsem because it I think it was supposed to be implementation detail.
Sure, why not? See the attached patch for helpers, exported GPL only of
course.
Thanks,
On Sun, 27 Mar 2005, Adam Belay wrote:
> Dynamic power management may require devices and drivers to transition
> between various physical and logical states. I would like to start a
> discussion on how these might be defined at the bus, driver, and class
> levels.
> Bus Level
> =
>
On Tue, 29 Mar 2005, Pavel Machek wrote:
> I don't really want us to try execve during resume... Could we simply
> artifically fail that execve with something if (in_suspend()) return
> -EINVAL; [except that in_suspend() just is not there, but there were
> some proposals to add it].
>
> Or just
On Mon, 28 Mar 2005, Alan Stern wrote:
> On Mon, 28 Mar 2005, Patrick Mochel wrote:
> > Do you have suggestions about an alternative (with code)?
>
> Here's something a little better than pseudocode but not as good as a
> patch... :-)
> To fill the first field in correctl
On Mon, 28 Mar 2005, Alan Stern wrote:
On Mon, 28 Mar 2005, Patrick Mochel wrote:
Do you have suggestions about an alternative (with code)?
Here's something a little better than pseudocode but not as good as a
patch... :-)
To fill the first field in correctly requires that klist
On Tue, 29 Mar 2005, Pavel Machek wrote:
I don't really want us to try execve during resume... Could we simply
artifically fail that execve with something if (in_suspend()) return
-EINVAL; [except that in_suspend() just is not there, but there were
some proposals to add it].
Or just avoid
On Sun, 27 Mar 2005, Adam Belay wrote:
Dynamic power management may require devices and drivers to transition
between various physical and logical states. I would like to start a
discussion on how these might be defined at the bus, driver, and class
levels.
snip
Bus Level
=
At
On Mon, 28 Mar 2005, David Brownell wrote:
> On Monday 28 March 2005 9:44 am, Patrick Mochel wrote:
>
> > How is this related to (8) above? Do you need some sort of protected,
> > short path through the core to add the device, but not bind it or add it
> > to t
On Sat, 26 Mar 2005, Alan Stern wrote:
> Let's move on to consider the new struct device.sem. You've
> recognized, like other people, that such a thing is necessary to
> protect drivers against simultaneous callbacks. But things aren't as
> simple as just sticking the semaphore into the
On Sat, 26 Mar 2005, Alan Stern wrote:
> Pat:
>
> Your recent series of driver model patches naturally divides up into
> two parts: those involved with implementing and using klists, and
> those involved with adding a semaphore to struct device. Let's
> consider these parts separately.
I've
On Sat, 26 Mar 2005, Alan Stern wrote:
Pat:
Your recent series of driver model patches naturally divides up into
two parts: those involved with implementing and using klists, and
those involved with adding a semaphore to struct device. Let's
consider these parts separately.
I've split
On Sat, 26 Mar 2005, Alan Stern wrote:
Let's move on to consider the new struct device.sem. You've
recognized, like other people, that such a thing is necessary to
protect drivers against simultaneous callbacks. But things aren't as
simple as just sticking the semaphore into the structure
On Mon, 28 Mar 2005, David Brownell wrote:
On Monday 28 March 2005 9:44 am, Patrick Mochel wrote:
How is this related to (8) above? Do you need some sort of protected,
short path through the core to add the device, but not bind it or add it
to the PM core?
Erm, why
On Fri, 25 Mar 2005, Greg KH wrote:
> On Fri, Mar 25, 2005 at 03:39:52PM -0800, Greg KH wrote:
> > But can you take a look at drivers/scsi/scsi_transport_spi.c, line 265?
> > That is also going to need fixing up somehow. Gotta love that FIXME
> > comment...
Heh, funky.
> Ok, the patch below
On Fri, 25 Mar 2005, Greg KH wrote:
On Fri, Mar 25, 2005 at 03:39:52PM -0800, Greg KH wrote:
But can you take a look at drivers/scsi/scsi_transport_spi.c, line 265?
That is also going to need fixing up somehow. Gotta love that FIXME
comment...
Heh, funky.
Ok, the patch below seems to
[EMAIL PROTECTED], 2005-03-24 18:58:45-08:00, [EMAIL PROTECTED]
[driver core] Call klist_del() instead of klist_remove().
- Can't wait on removing the current item in the list (the positive refcount
*because*
we are using it causes it to deadlock).
Signed-off-by: Patrick Mochel
those functions use the klists and the klists' spinlocks.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/drivers/base/bus.c b/drivers/base/bus.c
--- a/drivers/base/bus.c2005-03-24 20:33:31 -08:00
+++ b/drivers/base/bus.c2005-03-24 20:33:31 -08:00
@@ -17,8
[EMAIL PROTECTED], 2005-03-24 13:08:05-08:00, [EMAIL PROTECTED]
[driver core] Remove struct device::driver_list.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c 2005-03-24 20:33:16 -08:00
+++ b/d
[EMAIL PROTECTED], 2005-03-24 13:03:35-08:00, [EMAIL PROTECTED]
[driver core] Remove struct device::bus_list.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c 2005-03-24 20:33:23 -08:00
+++ b/d
[EMAIL PROTECTED], 2005-03-24 12:58:57-08:00, [EMAIL PROTECTED]
[klist] add klist_node_attached() to determine if a node is on a list or not.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/include/linux/klist.h b/include/linux/klist.h
--- a/include/linux/klist.h 2
[EMAIL PROTECTED], 2005-03-24 18:59:59-08:00, [EMAIL PROTECTED]
[klist] Don't reference NULL klist pointer in klist_remove().
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/lib/klist.c b/lib/klist.c
--- a/lib/klist.c 2005-03-24 20:33:01 -08:00
+++ b/lib/k
[EMAIL PROTECTED], 2005-03-24 19:03:59-08:00, [EMAIL PROTECTED]
[scsi] Use device_for_each_child() to unregister devices in
scsi_remove_target().
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
--- a/driver
[EMAIL PROTECTED], 2005-03-24 20:08:04-08:00, [EMAIL PROTECTED]
[driver core] Fix up bogus comment.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/drivers/base/driver.c b/drivers/base/driver.c
--- a/drivers/base/driver.c 2005-03-24 20:32:39 -08:00
+++ b/driver
of devices_subsys.rwsem.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c 2005-03-24 20:32:46 -08:00
+++ b/drivers/base/core.c 2005-03-24 20:32:46 -08:00
@@ -210,8 +210,7 @@
{
kobj_set_kset_s(dev, devices_
[EMAIL PROTECTED], 2005-03-24 10:50:24-08:00, [EMAIL PROTECTED]
[driver core] Use bus_for_each_{dev,drv} for driver binding.
- Now possible, since the lists are locked using the klist lock and not the
global rwsem.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
dif
[EMAIL PROTECTED], 2005-03-24 13:00:16-08:00, [EMAIL PROTECTED]
[usb] Fix up USB to use klist_node_attached() instead of list_empty() on
lists that will go away.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
--- a/drive
+++-
9 files changed, 92 insertions(+), 105 deletions(-)
through these ChangeSets:
<[EMAIL PROTECTED]> (05/03/24 1.2250)
[driver core] Fix up bogus comment.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> (05/03/24 1.2249)
[driver core] Use
[EMAIL PROTECTED], 2005-03-24 10:48:35-08:00, [EMAIL PROTECTED]
[driver core] Remove the unused device_find().
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c 2005-03-24 20:34:00 -08:00
+++ b/d
On Thu, 24 Mar 2005, Andrew Morton wrote:
> Laurent Riffard <[EMAIL PROTECTED]> wrote:
> >
> > hello,
> >
> > Same kinds of problem here. It depends on the removed module. I mean:
> > "rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod
> > ohci1394" hangs.
> >
> > Sysrq-T
On Thu, 24 Mar 2005, Andrew Morton wrote:
Laurent Riffard [EMAIL PROTECTED] wrote:
hello,
Same kinds of problem here. It depends on the removed module. I mean:
rmmod loop or rmmod pcspkr works. But rmmod snd_ens1371 or rmmod
ohci1394 hangs.
Sysrq-T when rmmoding snd_ens1371 :
[EMAIL PROTECTED], 2005-03-24 10:48:35-08:00, [EMAIL PROTECTED]
[driver core] Remove the unused device_find().
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c 2005-03-24 20:34:00 -08:00
+++ b/drivers/base
+++-
9 files changed, 92 insertions(+), 105 deletions(-)
through these ChangeSets:
[EMAIL PROTECTED] (05/03/24 1.2250)
[driver core] Fix up bogus comment.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
[EMAIL PROTECTED] (05/03/24 1.2249)
[driver core] Use a klist for device child
[EMAIL PROTECTED], 2005-03-24 10:50:24-08:00, [EMAIL PROTECTED]
[driver core] Use bus_for_each_{dev,drv} for driver binding.
- Now possible, since the lists are locked using the klist lock and not the
global rwsem.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers
[EMAIL PROTECTED], 2005-03-24 13:00:16-08:00, [EMAIL PROTECTED]
[usb] Fix up USB to use klist_node_attached() instead of list_empty() on
lists that will go away.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
--- a/drivers/usb
of devices_subsys.rwsem.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c 2005-03-24 20:32:46 -08:00
+++ b/drivers/base/core.c 2005-03-24 20:32:46 -08:00
@@ -210,8 +210,7 @@
{
kobj_set_kset_s(dev, devices_subsys
[EMAIL PROTECTED], 2005-03-24 20:08:04-08:00, [EMAIL PROTECTED]
[driver core] Fix up bogus comment.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/base/driver.c b/drivers/base/driver.c
--- a/drivers/base/driver.c 2005-03-24 20:32:39 -08:00
+++ b/drivers/base/driver.c
[EMAIL PROTECTED], 2005-03-24 19:03:59-08:00, [EMAIL PROTECTED]
[scsi] Use device_for_each_child() to unregister devices in
scsi_remove_target().
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
--- a/drivers/scsi
[EMAIL PROTECTED], 2005-03-24 18:59:59-08:00, [EMAIL PROTECTED]
[klist] Don't reference NULL klist pointer in klist_remove().
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/lib/klist.c b/lib/klist.c
--- a/lib/klist.c 2005-03-24 20:33:01 -08:00
+++ b/lib/klist.c
[EMAIL PROTECTED], 2005-03-24 12:58:57-08:00, [EMAIL PROTECTED]
[klist] add klist_node_attached() to determine if a node is on a list or not.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/include/linux/klist.h b/include/linux/klist.h
--- a/include/linux/klist.h 2005-03-24
[EMAIL PROTECTED], 2005-03-24 13:03:35-08:00, [EMAIL PROTECTED]
[driver core] Remove struct device::bus_list.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c 2005-03-24 20:33:23 -08:00
+++ b/drivers/base
[EMAIL PROTECTED], 2005-03-24 13:08:05-08:00, [EMAIL PROTECTED]
[driver core] Remove struct device::driver_list.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c 2005-03-24 20:33:16 -08:00
+++ b/drivers
those functions use the klists and the klists' spinlocks.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/base/bus.c b/drivers/base/bus.c
--- a/drivers/base/bus.c2005-03-24 20:33:31 -08:00
+++ b/drivers/base/bus.c2005-03-24 20:33:31 -08:00
@@ -17,8 +17,6
[EMAIL PROTECTED], 2005-03-24 18:58:45-08:00, [EMAIL PROTECTED]
[driver core] Call klist_del() instead of klist_remove().
- Can't wait on removing the current item in the list (the positive refcount
*because*
we are using it causes it to deadlock).
Signed-off-by: Patrick Mochel
On Wed, 23 Mar 2005, OGAWA Hirofumi wrote:
> Patrick Mochel <[EMAIL PROTECTED]> writes:
>
> > +void klist_del(struct klist_node * n)
> > +{
> > + struct klist * k = n->n_klist;
> > +
> > + spin_lock(>k_lock);
> > + klist_dec_and_del(n);
On Wed, 23 Mar 2005, OGAWA Hirofumi wrote:
Patrick Mochel [EMAIL PROTECTED] writes:
+void klist_del(struct klist_node * n)
+{
+ struct klist * k = n-n_klist;
+
+ spin_lock(k-k_lock);
+ klist_dec_and_del(n);
+ spin_unlock(k-k_lock);
+}
Can't we use atomic_dec_and_lock
On Tue, 22 Mar 2005, Christoph Hellwig wrote:
> On Mon, Mar 21, 2005 at 12:48:47PM -0800, Patrick Mochel wrote:
> >
> > [EMAIL PROTECTED], 2005-03-21 11:45:16-08:00, [EMAIL PROTECTED]
> > [klist] Add initial implementation of klist helpers.
>
> > This kli
On Tue, 22 Mar 2005, Christoph Hellwig wrote:
On Mon, Mar 21, 2005 at 12:48:47PM -0800, Patrick Mochel wrote:
[EMAIL PROTECTED], 2005-03-21 11:45:16-08:00, [EMAIL PROTECTED]
[klist] Add initial implementation of klist helpers.
This klist interface provides a couple of structures
to the ->suspend() or
->resume()
and ->probe() or ->release(), potentially saving a whole lot of headaches.
It also moves us a step closer to removing the bus rwsem, since it protects
the fields
in struct device that are modified by the core.
Signed-off-by: Patrick Mochel <[
[EMAIL PROTECTED], 2005-03-21 11:07:54-08:00, [EMAIL PROTECTED]
[pnp] Use driver_for_each_device() in drivers/pnp/driver.c instead of
manually walking list.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/drivers/pnp/driver.c b/drivers/pnp/driver.c
--- a/drive
[EMAIL PROTECTED], 2005-03-21 10:59:56-08:00, [EMAIL PROTECTED]
[driver core] Add driver_for_each_device().
Now there's an iterator for accessing each device bound to a driver.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/drivers/base/driver.c b/drivers/base/dr
from
that, some from devices, and some from drivers. And Two, it will make it
easier to do
some of the upcoming lock removal on that code..
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/drivers/base/Makefile b/drivers/base/Makefile
--- a/drivers/base/Makefile 2
[EMAIL PROTECTED], 2005-03-21 11:49:14-08:00, [EMAIL PROTECTED]
[driver core] Add a klist to struct bus_type for its devices.
- Use it for bus_for_each_dev().
- Use the klist spinlock instead of the bus rwsem.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/driver
: Patrick Mochel <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> (05/03/21 1.2237)
[driver core] Add a klist to struct bus_type for its drivers.
- Use it in bus_for_each_drv().
- Use the klist spinlock instead of the bus rwsem.
Signed-off-by: Patrick Mochel <[EMAIL PROTEC
[EMAIL PROTECTED], 2005-03-21 11:09:40-08:00, [EMAIL PROTECTED]
[usb] Use driver_for_each_device() instead of manually walking list.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
--- a/drivers/usb/core/usb.c2005-03
s to 0 is the node removed from the list.
klist_remove() will try to delete the node from the list and block
until it is actually removed. This is useful for objects (like devices)
that have been removed from the system and must be freed (but must wait
until all accessors have finished).
[EMAIL PROTECTED], 2005-03-21 12:00:18-08:00, [EMAIL PROTECTED]
[driver core] Add a klist to struct bus_type for its drivers.
- Use it in bus_for_each_drv().
- Use the klist spinlock instead of the bus rwsem.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru a/driver
driver_for_each_device() in driver_detach() so we don't deadlock on the
bus's rwsem.
- Remove ->devices.
- Move klist access and sysfs link access out from under device's semaphore,
since
they're synchronized through other means.
Signed-off-by: Patrick Mochel <[EMAIL PROTECTED]>
diff -Nru
driver_for_each_device() in driver_detach() so we don't deadlock on the
bus's rwsem.
- Remove -devices.
- Move klist access and sysfs link access out from under device's semaphore,
since
they're synchronized through other means.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers
[EMAIL PROTECTED], 2005-03-21 12:00:18-08:00, [EMAIL PROTECTED]
[driver core] Add a klist to struct bus_type for its drivers.
- Use it in bus_for_each_drv().
- Use the klist spinlock instead of the bus rwsem.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/base
.
klist_remove() will try to delete the node from the list and block
until it is actually removed. This is useful for objects (like devices)
that have been removed from the system and must be freed (but must wait
until all accessors have finished).
Signed-off-by: Patrick Mochel [EMAIL PROTECTED
[EMAIL PROTECTED], 2005-03-21 11:09:40-08:00, [EMAIL PROTECTED]
[usb] Use driver_for_each_device() instead of manually walking list.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
--- a/drivers/usb/core/usb.c2005-03-21 12:30
Mochel [EMAIL PROTECTED]
[EMAIL PROTECTED] (05/03/21 1.2237)
[driver core] Add a klist to struct bus_type for its drivers.
- Use it in bus_for_each_drv().
- Use the klist spinlock instead of the bus rwsem.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
[EMAIL PROTECTED] (05/03/21
[EMAIL PROTECTED], 2005-03-21 11:49:14-08:00, [EMAIL PROTECTED]
[driver core] Add a klist to struct bus_type for its devices.
- Use it for bus_for_each_dev().
- Use the klist spinlock instead of the bus rwsem.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/base
from
that, some from devices, and some from drivers. And Two, it will make it
easier to do
some of the upcoming lock removal on that code..
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/base/Makefile b/drivers/base/Makefile
--- a/drivers/base/Makefile 2005-03-21
[EMAIL PROTECTED], 2005-03-21 10:59:56-08:00, [EMAIL PROTECTED]
[driver core] Add driver_for_each_device().
Now there's an iterator for accessing each device bound to a driver.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/base/driver.c b/drivers/base/driver.c
[EMAIL PROTECTED], 2005-03-21 11:07:54-08:00, [EMAIL PROTECTED]
[pnp] Use driver_for_each_device() in drivers/pnp/driver.c instead of
manually walking list.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED]
diff -Nru a/drivers/pnp/driver.c b/drivers/pnp/driver.c
--- a/drivers/pnp/driver.c
to the -suspend() or
-resume()
and -probe() or -release(), potentially saving a whole lot of headaches.
It also moves us a step closer to removing the bus rwsem, since it protects
the fields
in struct device that are modified by the core.
Signed-off-by: Patrick Mochel [EMAIL PROTECTED
1 - 100 of 114 matches
Mail list logo
