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

[Kay Sievers]

On Sat, Apr 18, 2015 at 9:39 PM, Matthew Garrett <mjg59 at 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