From: "Rafael J. Wysocki" <rjw@sisk.pl> To: Kay Sievers <kay.sievers@suse.de> Cc: LKML <linux-kernel@vger.kernel.org>, Paul Mundt <lethal@linux-sh.org>, Greg KH <gregkh@suse.de>, Linux PM mailing list <linux-pm@lists.linux-foundation.org>, Russell King <linux@arm.linux.org.uk>, Magnus Damm <magnus.damm@gmail.com>, linux-sh@vger.kernel.org Subject: Re: [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev Date: Tue, 22 Mar 2011 22:05:01 +0000 [thread overview] Message-ID: <201103222305.01808.rjw@sisk.pl> (raw) In-Reply-To: <1300828356.1815.15.camel@zag> On Tuesday, March 22, 2011, Kay Sievers wrote: > On Tue, 2011-03-22 at 22:00 +0100, Rafael J. Wysocki wrote: > > On Tuesday, March 22, 2011, Kay Sievers wrote: > > > On Tue, 2011-03-22 at 21:30 +0100, Rafael J. Wysocki wrote: > > > > > > > > Perhaps there's a more straightforward way to make some files show up in > > > > sysfs on a specific path than defininig an otherwise useless bus type and > > > > device object? > > > > > > That's absolutely not the point. Please don't get yourself into that > > > thinking. If people want to "export stuff to userspace", they must not > > > invent new things. We need to get rid of the silly special cases. > > > > Why exactly? Do they actually hurt anyone and if so then how? > > Sure, "devices" are devices, and devices have well-defines set of > properties, not some magic directory, people can mess around with the > way they like. So it looks like the the problem is that the exported attributes happen to be under /sys/devices/. Would it still be a problem if they were somewhere else? > > > Userspace is not meant to learn subsystem specific rules for every new > > > thing. > > > > That depends a good deal of who's writing the user space in question. If > > that's the same person who's working on the particular part of the kernel, > > I don't see a big problem. > > Not for "devices". There are rules for devices, which are defined by the > driver core, and the sysdev stuff needs to go, because it does not fit > into that model. OK, I understand that. Now, there's stuff that doesn't really match the "device" model. Where is the right place to export that? Perhaps we should add something like /sys/platform/ (in analogy with /sys/firmware/)? > > > There is _one_ way to export device attributes, and that is > > > "struct device" today. > > > > > > If that's to expensive for anybody, just don't use sysfs. It's the rule > > > we have today. :) > > > > Oh, good to know. It's changed a bit since I last heard. Never mind. > > Oh, don't get me wrong, this is all is about "devices" not any other > controls. > > > Still, I won't let you change the things in /sys/power to struct devices, > > sorry about that. ;-) > > Fine as long as they are power specific things, and not "devices". You > don't have sysdevs there, right? :) No, I don't. > > And I wonder how are you going to deal with clocksource exporting things > > via the sysdev interface right now. I'd simply create two directories and > > put the two files into them and be done with that, but I guess that > > wouldn't fit into the model somehow, right? > > Nope, register a bus_type, and use struct device for all of them, Parent > them to /sys/devices/system/ if they should keep their location and > layout. Well, I'll be watching what happens to the patch trying to do that, but I'm not going to bet anything on its success. ;-) > > > > > That way userspace can properly enumerate them in a flat list > > > > > in /sys/bus/<bus_type name>/devices/*, and gets proper events on module > > > > > load and during system coldplug, and can hook into the usual hotplug > > > > > pathes to set/get these values instead of crawling magicly defined and > > > > > decoupled locations in /sys which can not express proper hierarchy, > > > > > classicication, or anything else that all other devices can just do. > > > > > > > > There's no hotplug involved or anything remotely like that AFAICS. > > > > There are simply static files as I said above, they are created > > > > early during system initialization and simply stay there. > > > > > > That's not the point. It's about a single way to retrieve information > > > about devices, extendability, and coldplug during bootup, where existing > > > devices need to be handled only after userspace is up. > > > > I'd say the case at hand has nothing to do with that. > > It has. As for CPUs. We can not do proper CPU-dependent module > autoloading, because the events happen before userspace runs, and > clodplug can not see the broken sysdevs, because they have no events to > re-trigger, like all others have. Well, as I said, would it be OK if the things in question happened to be located somewhere outside of /sys/devices/ ? > > > That is just a case of "hotplug" that has the same codepath for userspace, > > > even when the devices can never really come and go. > > > > My impression is that when you say "user space", you actually mean some > > _specific_ user space, don't you? > > On usual boxes it's udev/libudev and all the stuff around it. But > andreoid has the same stuff in their own way of doing it. So it's not > about an implementation in userspace, it's about a sane event and > classification interface for kernel-exported devices. Again tis is not > about any other stuff in /sys, only the "devices", and we want to have > only a single type, and a single way to handle it in userspace. OK > > > > > There is really no reason for any device being a magic and conceptually > > > > > broken sysdev today - just to be different from any other device the > > > > > kernel exports to userspace. > > > > > > > > It's not a "device being a sysdev", it's sysdevs being used for creating > > > > a user space interface, which isn't broken by itself. > > > > > > Yeah , absolutely. But if any device wants to export anything is _must_ > > > be a "struct device" today. If that does not fit, it must not use sysfs > > > at all. > > > > Well, it's not a "device wants to export something". It's platform code > > wanting to export some information related to the platform and I really > > don't see a reason why it should create bus types and device objects > > _specifically_ for that. It's just too wasteful, both in terms of memory > > and time needed for handling that in the device core. > > Because they are devices, and there is a lot to win, if the kernel > exports all "devices" in the same way. This is not about saving an inode > in /sys, it's the ability to do runtime device configuration with common > tools. If I understand you correctly, the goal is to have everything under /sys/devices/ been represented by struct device objects and there are good reasons to do that. In that case we either have to move the things exported via sysdevs somewhere else (presumably having to create that "somewhere" before), or we have to introduce struct device objects specifically for exporting them. I don't really think the latter approach will be very popular, so quite likely we'll need to have a plan for moving those things to different locations. Thanks, Rafael
WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@sisk.pl> To: Kay Sievers <kay.sievers@suse.de> Cc: LKML <linux-kernel@vger.kernel.org>, Paul Mundt <lethal@linux-sh.org>, Greg KH <gregkh@suse.de>, Linux PM mailing list <linux-pm@lists.linux-foundation.org>, Russell King <linux@arm.linux.org.uk>, Magnus Damm <magnus.damm@gmail.com>, linux-sh@vger.kernel.org Subject: Re: [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev Date: Tue, 22 Mar 2011 23:05:01 +0100 [thread overview] Message-ID: <201103222305.01808.rjw@sisk.pl> (raw) In-Reply-To: <1300828356.1815.15.camel@zag> On Tuesday, March 22, 2011, Kay Sievers wrote: > On Tue, 2011-03-22 at 22:00 +0100, Rafael J. Wysocki wrote: > > On Tuesday, March 22, 2011, Kay Sievers wrote: > > > On Tue, 2011-03-22 at 21:30 +0100, Rafael J. Wysocki wrote: > > > > > > > > Perhaps there's a more straightforward way to make some files show up in > > > > sysfs on a specific path than defininig an otherwise useless bus type and > > > > device object? > > > > > > That's absolutely not the point. Please don't get yourself into that > > > thinking. If people want to "export stuff to userspace", they must not > > > invent new things. We need to get rid of the silly special cases. > > > > Why exactly? Do they actually hurt anyone and if so then how? > > Sure, "devices" are devices, and devices have well-defines set of > properties, not some magic directory, people can mess around with the > way they like. So it looks like the the problem is that the exported attributes happen to be under /sys/devices/. Would it still be a problem if they were somewhere else? > > > Userspace is not meant to learn subsystem specific rules for every new > > > thing. > > > > That depends a good deal of who's writing the user space in question. If > > that's the same person who's working on the particular part of the kernel, > > I don't see a big problem. > > Not for "devices". There are rules for devices, which are defined by the > driver core, and the sysdev stuff needs to go, because it does not fit > into that model. OK, I understand that. Now, there's stuff that doesn't really match the "device" model. Where is the right place to export that? Perhaps we should add something like /sys/platform/ (in analogy with /sys/firmware/)? > > > There is _one_ way to export device attributes, and that is > > > "struct device" today. > > > > > > If that's to expensive for anybody, just don't use sysfs. It's the rule > > > we have today. :) > > > > Oh, good to know. It's changed a bit since I last heard. Never mind. > > Oh, don't get me wrong, this is all is about "devices" not any other > controls. > > > Still, I won't let you change the things in /sys/power to struct devices, > > sorry about that. ;-) > > Fine as long as they are power specific things, and not "devices". You > don't have sysdevs there, right? :) No, I don't. > > And I wonder how are you going to deal with clocksource exporting things > > via the sysdev interface right now. I'd simply create two directories and > > put the two files into them and be done with that, but I guess that > > wouldn't fit into the model somehow, right? > > Nope, register a bus_type, and use struct device for all of them, Parent > them to /sys/devices/system/ if they should keep their location and > layout. Well, I'll be watching what happens to the patch trying to do that, but I'm not going to bet anything on its success. ;-) > > > > > That way userspace can properly enumerate them in a flat list > > > > > in /sys/bus/<bus_type name>/devices/*, and gets proper events on module > > > > > load and during system coldplug, and can hook into the usual hotplug > > > > > pathes to set/get these values instead of crawling magicly defined and > > > > > decoupled locations in /sys which can not express proper hierarchy, > > > > > classicication, or anything else that all other devices can just do. > > > > > > > > There's no hotplug involved or anything remotely like that AFAICS. > > > > There are simply static files as I said above, they are created > > > > early during system initialization and simply stay there. > > > > > > That's not the point. It's about a single way to retrieve information > > > about devices, extendability, and coldplug during bootup, where existing > > > devices need to be handled only after userspace is up. > > > > I'd say the case at hand has nothing to do with that. > > It has. As for CPUs. We can not do proper CPU-dependent module > autoloading, because the events happen before userspace runs, and > clodplug can not see the broken sysdevs, because they have no events to > re-trigger, like all others have. Well, as I said, would it be OK if the things in question happened to be located somewhere outside of /sys/devices/ ? > > > That is just a case of "hotplug" that has the same codepath for userspace, > > > even when the devices can never really come and go. > > > > My impression is that when you say "user space", you actually mean some > > _specific_ user space, don't you? > > On usual boxes it's udev/libudev and all the stuff around it. But > andreoid has the same stuff in their own way of doing it. So it's not > about an implementation in userspace, it's about a sane event and > classification interface for kernel-exported devices. Again tis is not > about any other stuff in /sys, only the "devices", and we want to have > only a single type, and a single way to handle it in userspace. OK > > > > > There is really no reason for any device being a magic and conceptually > > > > > broken sysdev today - just to be different from any other device the > > > > > kernel exports to userspace. > > > > > > > > It's not a "device being a sysdev", it's sysdevs being used for creating > > > > a user space interface, which isn't broken by itself. > > > > > > Yeah , absolutely. But if any device wants to export anything is _must_ > > > be a "struct device" today. If that does not fit, it must not use sysfs > > > at all. > > > > Well, it's not a "device wants to export something". It's platform code > > wanting to export some information related to the platform and I really > > don't see a reason why it should create bus types and device objects > > _specifically_ for that. It's just too wasteful, both in terms of memory > > and time needed for handling that in the device core. > > Because they are devices, and there is a lot to win, if the kernel > exports all "devices" in the same way. This is not about saving an inode > in /sys, it's the ability to do runtime device configuration with common > tools. If I understand you correctly, the goal is to have everything under /sys/devices/ been represented by struct device objects and there are good reasons to do that. In that case we either have to move the things exported via sysdevs somewhere else (presumably having to create that "somewhere" before), or we have to introduce struct device objects specifically for exporting them. I don't really think the latter approach will be very popular, so quite likely we'll need to have a plan for moving those things to different locations. Thanks, Rafael
next prev parent reply other threads:[~2011-03-22 22:05 UTC|newest] Thread overview: 198+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-03-10 0:31 [RFC][PATCH 0/2] Allow subsystems to avoid using sysdevs for defining "core" PM callbacks Rafael J. Wysocki 2011-03-10 0:33 ` [RFC][PATCH 1/2] Introduce struct syscore_ops and related functionality Rafael J. Wysocki 2011-03-10 0:33 ` Rafael J. Wysocki 2011-03-10 3:33 ` [linux-pm] " Alan Stern 2011-03-10 10:42 ` Rafael J. Wysocki 2011-03-10 10:42 ` Rafael J. Wysocki 2011-03-10 11:30 ` [RFC][Update][PATCH " Rafael J. Wysocki 2011-03-11 17:11 ` Greg KH 2011-03-11 17:11 ` Greg KH 2011-03-11 20:13 ` Rafael J. Wysocki 2011-03-11 20:13 ` Rafael J. Wysocki 2011-03-11 20:16 ` Greg KH 2011-03-11 20:33 ` Rafael J. Wysocki 2011-03-11 20:33 ` Rafael J. Wysocki 2011-03-11 20:16 ` Greg KH 2011-03-10 11:30 ` Rafael J. Wysocki 2011-03-10 3:33 ` [RFC][PATCH " Alan Stern 2011-03-10 0:34 ` [RFC][PATCH 2/2] Convert several sysdev users to using struct syscore_ops Rafael J. Wysocki 2011-03-10 0:34 ` Rafael J. Wysocki 2011-03-11 17:12 ` Greg KH 2011-03-11 17:12 ` Greg KH 2011-03-11 20:29 ` Rafael J. Wysocki 2011-03-11 20:29 ` Rafael J. Wysocki 2011-03-11 20:33 ` Greg KH 2011-03-11 20:33 ` Greg KH 2011-03-11 20:45 ` Rafael J. Wysocki 2011-03-11 20:45 ` Rafael J. Wysocki 2011-03-10 13:05 ` [RFC][PATCH 0/2] Allow subsystems to avoid using sysdevs for defining "core" PM callbacks Kay Sievers 2011-03-10 13:05 ` Kay Sievers 2011-03-10 19:04 ` Rafael J. Wysocki 2011-03-10 19:04 ` Rafael J. Wysocki 2011-03-12 21:12 ` [PATCH 0/8] " Rafael J. Wysocki 2011-03-12 21:12 ` Rafael J. Wysocki 2011-03-12 21:13 ` [PATCH 1/8] PM / Core: Introcude struct syscore_ops Rafael J. Wysocki 2011-03-12 21:13 ` Rafael J. Wysocki 2011-03-12 21:15 ` [PATCH 2/8] x86: Use syscore_ops instead of sysdev classes and sysdevs Rafael J. Wysocki 2011-03-12 21:15 ` Rafael J. Wysocki 2011-03-13 14:23 ` Thomas Gleixner 2011-03-13 15:07 ` Rafael J. Wysocki 2011-03-13 15:07 ` Rafael J. Wysocki 2011-03-13 14:23 ` Thomas Gleixner 2011-03-12 21:16 ` [PATCH 3/8] ACPI: Use syscore_ops instead of sysdev class and sysdev Rafael J. Wysocki 2011-03-18 21:38 ` Len Brown 2011-03-18 21:38 ` Len Brown 2011-03-12 21:16 ` Rafael J. Wysocki 2011-03-12 21:17 ` [PATCH 4/8] timekeeping: " Rafael J. Wysocki 2011-03-13 13:56 ` Thomas Gleixner 2011-03-13 13:56 ` Thomas Gleixner 2011-03-13 15:08 ` Rafael J. Wysocki 2011-03-13 15:08 ` Rafael J. Wysocki 2011-03-12 21:17 ` Rafael J. Wysocki 2011-03-12 21:18 ` [PATCH 5/8] PCI / Intel IOMMU: " Rafael J. Wysocki 2011-03-12 21:18 ` Rafael J. Wysocki 2011-06-02 17:30 ` Tony Luck 2011-06-06 17:57 ` Rafael J. Wysocki 2011-06-06 17:58 ` Luck, Tony 2011-06-06 17:58 ` Luck, Tony 2011-06-06 17:57 ` Rafael J. Wysocki 2011-06-02 17:30 ` Tony Luck 2011-03-12 21:18 ` [PATCH 6/8] KVM: " Rafael J. Wysocki 2011-03-12 21:18 ` Rafael J. Wysocki 2011-03-12 21:20 ` [PATCH 7/8] cpufreq: Use syscore_ops for boot CPU suspend/resume Rafael J. Wysocki 2011-03-12 21:20 ` Rafael J. Wysocki 2011-03-15 21:43 ` [Update, v2] " Rafael J. Wysocki 2011-03-15 21:43 ` Rafael J. Wysocki 2011-03-12 21:21 ` [PATCH 8/8] Introduce ARCH_NO_SYSDEV_OPS config option Rafael J. Wysocki 2011-03-13 13:55 ` Thomas Gleixner 2011-03-13 13:55 ` Thomas Gleixner 2011-03-13 15:30 ` [Update] " Rafael J. Wysocki 2011-03-13 15:30 ` Rafael J. Wysocki 2011-03-12 21:21 ` Rafael J. Wysocki 2011-03-13 13:02 ` [PATCH 9-10/10] Allow subsystems to avoid using sysdevs for defining "core" PM callbacks Rafael J. Wysocki 2011-03-13 13:02 ` Rafael J. Wysocki 2011-03-13 13:03 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev R. J. Wysocki 2011-03-13 13:03 ` R. J. Wysocki 2011-03-17 8:20 ` Paul Mundt 2011-03-17 8:20 ` Paul Mundt 2011-03-19 0:47 ` Rafael J. Wysocki 2011-03-19 0:47 ` Rafael J. Wysocki 2011-03-22 14:04 ` Paul Mundt 2011-03-22 14:04 ` Paul Mundt 2011-03-22 14:04 ` Paul Mundt 2011-03-22 14:19 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev Kay Sievers 2011-03-22 14:19 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev Kay Sievers 2011-03-22 20:30 ` Rafael J. Wysocki 2011-03-22 20:30 ` Rafael J. Wysocki 2011-03-22 20:30 ` Rafael J. Wysocki 2011-03-22 20:39 ` Kay Sievers 2011-03-22 20:39 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev Kay Sievers 2011-03-22 20:39 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev Kay Sievers 2011-03-22 21:00 ` Rafael J. Wysocki 2011-03-22 21:00 ` Rafael J. Wysocki 2011-03-22 21:00 ` Rafael J. Wysocki 2011-03-22 21:12 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev Kay Sievers 2011-03-22 21:12 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev Kay Sievers 2011-03-22 21:49 ` Paul Mundt 2011-03-22 21:49 ` Paul Mundt 2011-03-22 21:49 ` Paul Mundt 2011-03-22 22:00 ` Kay Sievers 2011-03-22 22:00 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev Kay Sievers 2011-03-22 22:00 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev Kay Sievers 2011-03-22 22:23 ` Rafael J. Wysocki 2011-03-22 22:23 ` Rafael J. Wysocki 2011-03-22 22:23 ` Rafael J. Wysocki 2011-03-22 22:44 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev Kay Sievers 2011-03-22 22:44 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev Kay Sievers 2011-03-22 23:32 ` Rafael J. Wysocki 2011-03-22 23:32 ` Rafael J. Wysocki 2011-03-22 23:32 ` Rafael J. Wysocki 2011-03-22 23:46 ` Kay Sievers 2011-03-22 23:46 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev Kay Sievers 2011-03-22 23:46 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev Kay Sievers 2011-03-22 23:50 ` Rafael J. Wysocki 2011-03-22 23:50 ` Rafael J. Wysocki 2011-03-22 23:50 ` Rafael J. Wysocki 2011-03-23 9:45 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev Russell King - ARM Linux 2011-03-23 9:45 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev Russell King - ARM Linux 2011-03-23 9:45 ` Russell King - ARM Linux 2011-03-22 22:44 ` Kay Sievers 2011-03-22 22:23 ` Paul Mundt 2011-03-22 22:23 ` Paul Mundt 2011-03-23 11:12 ` Mark Brown 2011-03-23 11:12 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev Mark Brown 2011-03-23 11:12 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev Mark Brown 2011-03-23 11:28 ` Paul Mundt 2011-03-23 11:28 ` Paul Mundt 2011-03-23 11:28 ` Paul Mundt 2011-03-22 22:23 ` Paul Mundt 2011-03-22 22:05 ` Rafael J. Wysocki [this message] 2011-03-22 22:05 ` Rafael J. Wysocki 2011-03-22 22:20 ` Kay Sievers 2011-03-22 22:20 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev Kay Sievers 2011-03-22 22:20 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev Kay Sievers 2011-03-22 22:42 ` Rafael J. Wysocki 2011-03-22 22:42 ` Rafael J. Wysocki 2011-03-22 22:42 ` Rafael J. Wysocki 2011-03-22 22:56 ` Kay Sievers 2011-03-22 22:56 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev Kay Sievers 2011-03-22 22:56 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev Kay Sievers 2011-03-22 23:05 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev Kay Sievers 2011-03-22 23:05 ` [PATCH 9/10] sh: Use struct syscore_ops instead of sysdev class and sysdev Kay Sievers 2011-03-22 23:47 ` Rafael J. Wysocki 2011-03-22 23:47 ` Rafael J. Wysocki 2011-03-22 23:47 ` Rafael J. Wysocki 2011-03-22 23:05 ` Kay Sievers 2011-03-22 22:05 ` Rafael J. Wysocki 2011-03-22 21:12 ` Kay Sievers 2011-03-22 14:19 ` Kay Sievers 2011-03-22 20:19 ` Rafael J. Wysocki 2011-03-22 20:19 ` Rafael J. Wysocki 2011-03-22 20:19 ` Rafael J. Wysocki 2011-03-23 9:59 ` Paul Mundt 2011-03-23 9:59 ` Paul Mundt 2011-03-23 20:39 ` Rafael J. Wysocki 2011-03-23 20:39 ` Rafael J. Wysocki 2011-03-23 20:39 ` Rafael J. Wysocki 2011-03-23 9:59 ` Paul Mundt 2011-03-19 0:47 ` Rafael J. Wysocki 2011-03-17 8:20 ` Paul Mundt 2011-03-13 13:03 ` R. J. Wysocki 2011-03-13 13:04 ` [PATCH 10/10] ARM: Use struct syscore_ops instead of sysdevs for PM in timer and leds Rafael J. Wysocki 2011-03-13 13:04 ` Rafael J. Wysocki 2011-03-13 13:04 ` Rafael J. Wysocki 2011-03-14 9:06 ` Stephen Boyd 2011-03-14 9:06 ` [PATCH 10/10] ARM: Use struct syscore_ops instead of sysdevs Stephen Boyd 2011-03-14 9:06 ` [PATCH 10/10] ARM: Use struct syscore_ops instead of sysdevs for PM in timer and leds Stephen Boyd 2011-03-14 19:54 ` [Update] " Rafael J. Wysocki 2011-03-14 19:54 ` Rafael J. Wysocki 2011-03-14 19:54 ` Rafael J. Wysocki 2011-03-13 13:02 ` [PATCH 9-10/10] Allow subsystems to avoid using sysdevs for defining "core" PM callbacks Rafael J. Wysocki 2011-03-21 23:31 ` [PATCH 0/6] Do not use sysdevs for implementing "core" PM operations on x86 Rafael J. Wysocki 2011-03-21 23:31 ` Rafael J. Wysocki 2011-03-21 23:34 ` [PATCH 1/6] x86: Use syscore_ops instead of sysdev classes and sysdevs Rafael J. Wysocki 2011-03-21 23:34 ` Rafael J. Wysocki 2011-03-21 23:35 ` [PATCH 2/6] timekeeping: Use syscore_ops instead of sysdev class and sysdev Rafael J. Wysocki 2011-03-21 23:35 ` Rafael J. Wysocki 2011-03-21 23:36 ` [PATCH 3/6] PCI / Intel IOMMU: " Rafael J. Wysocki 2011-03-22 10:57 ` Joerg Roedel 2011-03-22 22:07 ` Rafael J. Wysocki 2011-03-22 22:07 ` Rafael J. Wysocki 2011-03-23 7:48 ` Roedel, Joerg 2011-03-23 7:48 ` Roedel, Joerg 2011-03-22 10:57 ` Joerg Roedel 2011-03-21 23:36 ` Rafael J. Wysocki 2011-03-21 23:37 ` [PATCH 4/6] KVM: " Rafael J. Wysocki 2011-03-21 23:37 ` Rafael J. Wysocki 2011-03-22 9:18 ` Avi Kivity 2011-03-22 9:18 ` Avi Kivity 2011-03-21 23:38 ` [PATCH 5/6] cpufreq: Use syscore_ops for boot CPU suspend/resume (v2) Rafael J. Wysocki 2011-03-21 23:38 ` Rafael J. Wysocki 2011-03-21 23:38 ` [PATCH 6/6] Introduce ARCH_NO_SYSDEV_OPS config option (v2) Rafael J. Wysocki 2011-03-21 23:38 ` Rafael J. Wysocki 2011-03-22 10:32 ` [PATCH 0/6] Do not use sysdevs for implementing "core" PM operations on x86 Ingo Molnar 2011-03-22 20:33 ` Rafael J. Wysocki 2011-03-22 20:33 ` Rafael J. Wysocki 2011-03-25 22:51 ` [GIT PULL] More power management updates for 2.6.39 Rafael J. Wysocki 2011-03-25 22:51 ` Rafael J. Wysocki 2011-03-22 10:32 ` [PATCH 0/6] Do not use sysdevs for implementing "core" PM operations on x86 Ingo Molnar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=201103222305.01808.rjw@sisk.pl \ --to=rjw@sisk.pl \ --cc=gregkh@suse.de \ --cc=kay.sievers@suse.de \ --cc=lethal@linux-sh.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@lists.linux-foundation.org \ --cc=linux-sh@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=magnus.damm@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.