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

Kay Sievers kay at vrfy.org
Mon Apr 20 13:01:11 PDT 2015


On Mon, Apr 20, 2015 at 8:11 PM, David Herrmann <dh.herrmann at gmail.com> wrote:
> Hi
>
> On Sun, Apr 19, 2015 at 11:46 PM, Matthew Garrett <mjg59 at 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


More information about the systemd-devel mailing list