Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
On Sun, Apr 19, 2015 at 10:46:40PM +0100, Matthew Garrett wrote: I'm not convinced that any such broad matches for power management belong into udev at all. Udev can carry specific device matches, or carry data that cannot be determined from the device itself, like the mouse resolution and such, but like in these rules, reading the vendor from the kernel and unconditionally flipping a bit back into the kernel does not look like a task for udev or userspace in general. Is there any possibility that you can be convinced? I think they should go into the kernel as well, given that people update their kernel, but don't update their userspace components. Have we tried this in the kernel? How prelevant are problems really going to be that we need to determine stuff like if this PCI device is present then this mouse way over here can actually be autosuspended? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
Hi On Sun, Apr 19, 2015 at 11:46 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Sun, Apr 19, 2015 at 11:37:31PM +0200, Kay Sievers wrote: I'm not convinced that any such broad matches for power management belong into udev at all. Udev can carry specific device matches, or carry data that cannot be determined from the device itself, like the mouse resolution and such, but like in these rules, reading the vendor from the kernel and unconditionally flipping a bit back into the kernel does not look like a task for udev or userspace in general. Is there any possibility that you can be convinced? I'd much prefer if this was hwdb based. This way, we have a sane database that just sets something like POWER_CONTROL=foobar, which we can then apply via udev. Given that the power-control issues seem to be totally random, hwdb really sounds like the nicer solution. Any reason why hwdb would not work? Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
On Mon, Apr 20, 2015 at 8:11 PM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Sun, Apr 19, 2015 at 11:46 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Sun, Apr 19, 2015 at 11:37:31PM +0200, Kay Sievers wrote: I'm not convinced that any such broad matches for power management belong into udev at all. Udev can carry specific device matches, or carry data that cannot be determined from the device itself, like the mouse resolution and such, but like in these rules, reading the vendor from the kernel and unconditionally flipping a bit back into the kernel does not look like a task for udev or userspace in general. Is there any possibility that you can be convinced? I'd much prefer if this was hwdb based. This way, we have a sane database that just sets something like POWER_CONTROL=foobar, which we can then apply via udev. Given that the power-control issues seem to be totally random, hwdb really sounds like the nicer solution. Any reason why hwdb would not work? The question here is more why systemd/udev should get into the power management business at all. So far, applying unconditional policy sounds like a job for the kernel, not userspace. Either it can be safely ensabled, then it can be done right away by the kernel driver, or it isn't safe, then using udev does not solve any problem. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
On Sat, Apr 18, 2015 at 9:39 PM, Matthew Garrett mj...@srcf.ucam.org wrote: (Resending from the correct address) On Sat, Apr 18, 2015 at 07:51:26PM +0200, Kay Sievers wrote: It looks like an unconditional static assignment. Why should udev carry this? We generally do not want to do things like that. Udev can help if there is conditional policy or complex cross-subsystem knowledge is needed, but this looks just like a job for the kernel and not userspace. 1) having this in udev makes it easier for users to alter the configuration - the kernel can then afford to be conservative until we enable power management, rather than potentially breaking the device the moment pm is enabled without any ability to recover it. There is no significant difference between a default unconditional udev setting and a kernel command line option to control such behavior if needed. 2) this config is currently static, but the appropriate policy may turn out to be more complicated in some scenarios (interactions between devices and their upstream bridges, for instance, or USB Bluetooth controllers that are on-die with a PCI wifi controller without having a common exposed bus topology yet still having pm interactions). Splitting this between udev and the kernel makes it more difficult to determine the source of the policy and debug it. Either the setting is safe to use or not, the source of this policy is not really relevant here. The loop through userspace does not sound useful. 3) we already have examples of this in udev, so people already expect to find it here. Which should be a reason to carefully check these examples if they should stay in udev, not a reason to justify to add more. I'm not convinced that any such broad matches for power management belong into udev at all. Udev can carry specific device matches, or carry data that cannot be determined from the device itself, like the mouse resolution and such, but like in these rules, reading the vendor from the kernel and unconditionally flipping a bit back into the kernel does not look like a task for udev or userspace in general. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
On Sun, Apr 19, 2015 at 11:37:31PM +0200, Kay Sievers wrote: On Sat, Apr 18, 2015 at 9:39 PM, Matthew Garrett mj...@srcf.ucam.org wrote: 1) having this in udev makes it easier for users to alter the configuration - the kernel can then afford to be conservative until we enable power management, rather than potentially breaking the device the moment pm is enabled without any ability to recover it. There is no significant difference between a default unconditional udev setting and a kernel command line option to control such behavior if needed. The command line option would need to be per-device, so I can't see a terribly good way to express that. 2) this config is currently static, but the appropriate policy may turn out to be more complicated in some scenarios (interactions between devices and their upstream bridges, for instance, or USB Bluetooth controllers that are on-die with a PCI wifi controller without having a common exposed bus topology yet still having pm interactions). Splitting this between udev and the kernel makes it more difficult to determine the source of the policy and debug it. Either the setting is safe to use or not, the source of this policy is not really relevant here. The loop through userspace does not sound useful. There's no mechanism in the kernel to say Enable power management on this USB device only if a specific PCI device doesn't exist. This kind of policy is much easier to express in userspace than in the kernel. 3) we already have examples of this in udev, so people already expect to find it here. Which should be a reason to carefully check these examples if they should stay in udev, not a reason to justify to add more. Well, that's certainly an option. I'm not convinced that any such broad matches for power management belong into udev at all. Udev can carry specific device matches, or carry data that cannot be determined from the device itself, like the mouse resolution and such, but like in these rules, reading the vendor from the kernel and unconditionally flipping a bit back into the kernel does not look like a task for udev or userspace in general. Is there any possibility that you can be convinced? -- Matthew Garrett | mj...@srcf.ucam.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
On Sat, Apr 18, 2015 at 6:11 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
From: Matthew Garrett mj...@coreos.com
PCI power management seems to work fine on Intel HDA controllers, so let's
turn that on. We can expand this to other vendors based on user feedback.
+ACTION==add, SUBSYSTEM==pci, ATTR{class}==0x040300,
ATTR{vendor}==0x8086, ATTR{power/control}=auto
It looks like an unconditional static assignment.
Why should udev carry this? We generally do not want to do things like
that. Udev can help if there is conditional policy or complex
cross-subsystem knowledge is needed, but this looks just like a job
for the kernel and not userspace.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
(Resending from the correct address) On Sat, Apr 18, 2015 at 07:51:26PM +0200, Kay Sievers wrote: It looks like an unconditional static assignment. Why should udev carry this? We generally do not want to do things like that. Udev can help if there is conditional policy or complex cross-subsystem knowledge is needed, but this looks just like a job for the kernel and not userspace. 1) having this in udev makes it easier for users to alter the configuration - the kernel can then afford to be conservative until we enable power management, rather than potentially breaking the device the moment pm is enabled without any ability to recover it. 2) this config is currently static, but the appropriate policy may turn out to be more complicated in some scenarios (interactions between devices and their upstream bridges, for instance, or USB Bluetooth controllers that are on-die with a PCI wifi controller without having a common exposed bus topology yet still having pm interactions). Splitting this between udev and the kernel makes it more difficult to determine the source of the policy and debug it. 3) we already have examples of this in udev, so people already expect to find it here. -- Matthew Garrett | mj...@srcf.ucam.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
