[systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers

[Matthew Garrett]

On Sun, Apr 19, 2015 at 11:37:31PM +0200, Kay Sievers wrote:
> On Sat, Apr 18, 2015 at 9:39 PM, Matthew Garrett <mjg59 at 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 | mjg59 at srcf.ucam.org