Re: [systemd-devel] [PATCH] Add support for Intel Rapid Start

2013-10-13 Thread Matthew Garrett
On Sun, Oct 13, 2013 at 10:09:28PM +0200, Bastien Nocera wrote: On Sun, 2013-10-13 at 20:57 +0100, Matthew Garrett wrote: On Sun, Oct 13, 2013 at 09:50:59PM +0200, Bastien Nocera wrote: +r = read_one_line_file(/sys/bus/acpi/devices/INT3392:00/wakeup_events, p); /sys/bus

Re: [systemd-devel] [PATCH] Add support for Intel Rapid Start

2013-10-13 Thread Matthew Garrett
a + * critical level */ +if (p[0] == '3' p[1] == '\0') +return true; That seems a little harsh - not all firmware exposes the settings for this. I think it's legitimate to just program it yourself. -- Matthew Garrett | mj...@srcf.ucam.org

Re: [systemd-devel] Supermicro X8ST3 KVM-over-IP keyboard doesn't work with the existing rule in 42-usb-hid-pm.rules

2012-12-06 Thread Matthew Garrett
On Thu, Dec 06, 2012 at 05:05:17PM +0100, Kay Sievers wrote: Matthew, any idea? Remove the rule? Sure. My suspicion is that this is fine with some firmware versions, but figuring out which is going to be a pain. Probably easiest to drop it. -- Matthew Garrett | mj...@srcf.ucam.org

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

2015-04-19 Thread 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 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

[systemd-devel] [PATCH 3/3] rules: Enable runtime power management on built-in USB Bluetooth controllers

2015-04-18 Thread Matthew Garrett
From: Matthew Garrett mj...@coreos.com If a Bluetooth controller is built into the machine, it should be safe to enable runtime power management on it. Let's do so. --- Makefile.am | 3 ++- rules/90-usb-bluetooth-pm.rules | 8 2 files changed, 10 insertions(+), 1

[systemd-devel] [PATCH 2/3] rules: Enable runtime device power management on a subset of HDA codecs

2015-04-18 Thread Matthew Garrett
From: Matthew Garrett mj...@coreos.com 4.1 ports HDA codec power management to the standard runtime PM framework, which means we have per-codec control over whether it's enabled or not. We've traditionally left this disabled because on some codecs enabling it causes popping noises on power

[systemd-devel] Enable runtime power management on more hardware

2015-04-18 Thread Matthew Garrett
Modern hardware is very sensitive to peripheral power management state. While the kernel supports runtime PM on a lot of hardware, it's mostly disabled by default due to the risk of it breaking a subset of devices. Let's turn it on on devices where we have reasonable confidence in it working, with

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

2015-04-18 Thread Matthew Garrett
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. --- Makefile.am | 3 ++- rules/90-hda-controller-pm.rules | 3 +++ 2 files changed, 5

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

2015-04-18 Thread Matthew Garrett
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

[systemd-devel] [PATCH] 42-usb-hid-pm.rules: Fix tests for removable state

2015-04-08 Thread Matthew Garrett
From: Matthew Garrett mj...@coreos.com We only care about whether our direct parent is removable, not whether any further points up the tree are - the kernel will take care of policy for those itself. This enables autosuspend on devices where the root hub reports that its removable state

Re: [systemd-devel] systemd and chroot()

2019-06-04 Thread Matthew Garrett
On Tue, Jun 4, 2019 at 9:42 AM Steve Dickson wrote: > AVC avc: denied { sys_chroot } for pid=2919 comm="rpc.mountd" > capability=18 scontext=system_u:system_r:nfsd_t:s0 > tcontext=system_u:system_r:nfsd_t:s0 tclass=capability permissive=0 This is an SELinux policy violation, nothing to do

Re: [systemd-devel] Antw: Re: Antw: Re: Antw: Re: rdrand generated with march=winchip-c6 in systemd-241

2019-05-14 Thread Matthew Garrett
> The point I was trying to make was: "CPUID" and the model-specific registers > (thus the name) depend very much on the CPU being used. While the kernel makes > grat efforts to get things right, I wondered whether it's the best idea > whether > to repeat that effort in an application program.

Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c

2019-11-05 Thread Matthew Garrett
On Tue, Nov 5, 2019 at 8:33 AM Chris Murphy wrote: > > On Fri, Nov 1, 2019 at 2:31 PM Matthew Garrett wrote: > > > > The initrd already contains a UI stack in order to permit disk unlock > > at boot time, so this really doesn't seem like a problem? > > It's a v

Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c

2019-11-01 Thread Matthew Garrett
On Thu, Oct 31, 2019 at 5:06 PM Lennart Poettering wrote: > Paging doesn't allow that really. It's always ugly. You'd have to have > your own UI stack in the initrd, i.e. basically have an alternative > root disk, that possesses the screen exclusively as long as the system > is up but not