Re: [systemd-devel] [PATCH] Add support for Intel Rapid Start
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/acpi/drivers/intel_rapid_start/*/wakeup_events would be better, if there's any way to use wildcards here. It's possible that later models will change the ACPI ID while still exposing the same userspace UI. There's no way to use globs here, but I can look for the first directory under there, would that be enough? systemd developers, is there a helper for that already? Hrm. What defines first directory? There's also a module directory, which makes things harder. I guess there's an argument for integrating this into the core kernel power management in some way - I'll talk to Rafael about that in Edinburgh. Then we shouldn't check the value, and set it, but I'm not sure I should be doing that in the has_rapid_start() function. Sounds fair. I guess that in the future, we should allow setting and modifying the wakeup timer value, but I'd want to figure out if and how to present it in the UI before that. I'd be happy with a decent default value like 2 hours and be done with it. Sure. -- 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] Add support for Intel Rapid Start
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/acpi/drivers/intel_rapid_start/*/wakeup_events would be better, if there's any way to use wildcards here. It's possible that later models will change the ACPI ID while still exposing the same userspace UI. +/* We only support rapid start if we have both values set: + * 1: Wake to enter hibernation when the wakeup timer expires + * 2: Wake to enter hibernation when the battery reaches 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 ___ 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
[systemd-devel] [PATCH 3/3] rules: Enable runtime power management on built-in USB Bluetooth controllers
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 deletion(-)
create mode 100644 rules/90-usb-bluetooth-pm.rules
diff --git a/Makefile.am b/Makefile.am
index 40cf101..8463a54 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3754,7 +3754,8 @@ dist_udevrules_DATA += \
rules/78-sound-card.rules \
rules/80-net-setup-link.rules \
rules/90-hda-controller-pm.rules \
- rules/90-hda-codec-pm.rules
+ rules/90-hda-codec-pm.rules \
+ rules/90-usb-bluetooth-pm.rules
nodist_udevrules_DATA += \
rules/99-systemd.rules
diff --git a/rules/90-usb-bluetooth-pm.rules b/rules/90-usb-bluetooth-pm.rules
new file mode 100644
index 000..ea535f0
--- /dev/null
+++ b/rules/90-usb-bluetooth-pm.rules
@@ -0,0 +1,8 @@
+# USB devices that are internal to the machine should also be safe to
autosuspend
+
+ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb,
ATTR{removable}==removable, GOTO=usb_bluetooth_pm_end
+ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb,
ATTR{removable}==unknown, GOTO=usb_bluetooth_pm_end
+
+ACTION==add, SUBSYSTEM==usb, ATTR{bDeviceClass}==e0,
ATTR{bDeviceSubClass}==01, ATTR{bDeviceProtocol}==01,
TEST==power/control, ATTR{power/control}=auto
+
+LABEL=usb_bluetooth_pm_end
--
2.3.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] rules: Enable runtime device power management on a subset of HDA codecs
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 transitions, but now we can whitelist on a
per-codec basis. This patch simply enables it for the Broadwell HDMI codec
with the aim that we can add more based on user feedback.
---
Makefile.am | 3 ++-
rules/90-hda-codec-pm.rules | 4
2 files changed, 6 insertions(+), 1 deletion(-)
create mode 100644 rules/90-hda-codec-pm.rules
diff --git a/Makefile.am b/Makefile.am
index d23c428..40cf101 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3753,7 +3753,8 @@ dist_udevrules_DATA += \
rules/75-net-description.rules \
rules/78-sound-card.rules \
rules/80-net-setup-link.rules \
- rules/90-hda-controller-pm.rules
+ rules/90-hda-controller-pm.rules \
+ rules/90-hda-codec-pm.rules
nodist_udevrules_DATA += \
rules/99-systemd.rules
diff --git a/rules/90-hda-codec-pm.rules b/rules/90-hda-codec-pm.rules
new file mode 100644
index 000..e0c55e1
--- /dev/null
+++ b/rules/90-hda-codec-pm.rules
@@ -0,0 +1,4 @@
+# Enable autosuspend for some HDA codecs
+
+ACTION==add, SUBSYSTEM==hdaudio, ATTR{chip_name}==Broadwell HDMI,
ATTR{power/control}=auto
+
--
2.3.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Enable runtime power management on more hardware
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 the aim of extending this to more devices as we receive user feedback. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
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 insertions(+), 1 deletion(-)
create mode 100644 rules/90-hda-controller-pm.rules
diff --git a/Makefile.am b/Makefile.am
index 68d8252..d23c428 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3752,7 +3752,8 @@ dist_udevrules_DATA += \
rules/70-touchpad.rules \
rules/75-net-description.rules \
rules/78-sound-card.rules \
- rules/80-net-setup-link.rules
+ rules/80-net-setup-link.rules \
+ rules/90-hda-controller-pm.rules
nodist_udevrules_DATA += \
rules/99-systemd.rules
diff --git a/rules/90-hda-controller-pm.rules b/rules/90-hda-controller-pm.rules
new file mode 100644
index 000..2f915be
--- /dev/null
+++ b/rules/90-hda-controller-pm.rules
@@ -0,0 +1,3 @@
+# Enable autosuspend for some HDA interfaces
+
+ACTION==add, SUBSYSTEM==pci, ATTR{class}==0x040300,
ATTR{vendor}==0x8086, ATTR{power/control}=auto
--
2.3.5
___
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
[systemd-devel] [PATCH] 42-usb-hid-pm.rules: Fix tests for removable state
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 is unknown.
---
rules/42-usb-hid-pm.rules | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/rules/42-usb-hid-pm.rules b/rules/42-usb-hid-pm.rules
index 4c300da..3721219 100644
--- a/rules/42-usb-hid-pm.rules
+++ b/rules/42-usb-hid-pm.rules
@@ -28,9 +28,9 @@ ACTION==add, SUBSYSTEM==usb, ATTR{idVendor}==14dd,
ATTR{idProduct}==0002
# USB HID devices that are internal to the machine should also be safe to
autosuspend
-ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb,
ATTRS{removable}==removable, GOTO=usb_hid_pm_end
-ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb,
ATTRS{removable}==unknown, GOTO=usb_hid_pm_end
+ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb,
ATTR{../removable}==removable, GOTO=usb_hid_pm_end
+ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb,
ATTR{../removable}==unknown, GOTO=usb_hid_pm_end
-ACTION==add, SUBSYSTEM==usb, ATTR{bInterfaceClass}==03,
ATTRS{removable}==fixed, TEST==../power/control,
ATTR{../power/control}=auto
+ACTION==add, SUBSYSTEM==usb, ATTR{bInterfaceClass}==03,
ATTR{../removable}==fixed, TEST==../power/control,
ATTR{../power/control}=auto
LABEL=usb_hid_pm_end
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and chroot()
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 with systemd.
You're probably not seeing it when you run the daemon by hand because
the SELinux policy doesn't specify a transition in that case, so the
daemon doesn't end up running in the confined context.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Antw: Re: rdrand generated with march=winchip-c6 in systemd-241
> 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. Compiler intrinsics are supposed to provide correct results independent of the OS that they're running on. It's not unreasonable for code to expect them to behave correctly. In this case it seems that an assumption that gcc made that's true for most CPUs isn't true for a specific (20 years old) CPU - that's a bug in gcc, and it's reasonable to ask for it to be fixed. There's a separate question of whether depending on the kernel for this information rather than using the compiler was the best solution, but it's pretty justified for applications to presume that the compiler works the way that the compiler is documented as behaving. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
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 very small and limited UI stack. At least the GNOME developers > I've discussed it with, this environment has all kinds of a11y, i18n, > and keymapping problems. To solve it means either baking a significant > portion of the GNOME stack into the initramfs, or some kind of magic > because the resources don't exist to create a minimized GNOME stack > that could achieve this. And so far the effort has been to try and > make the initramfs smaller, and more generic. I agree that the Plymouth UI stack isn't ideal for various reasons, but it's the UI stack that's used for unlocking the drive during boot so reusing it doesn't make things any worse than they already are. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c
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 unlocked yet. 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? Switch VTs before suspend, suspend the LUKS devices so all access blocks and the keys are dropped, suspend, resume, run the unlock codepath from initramfs again, switch VTs back, we're good? Things are a little more complicated if you want to use the disk unlock phrase to also trigger desktop unlock, but everything else seems reasonably straightforward - processes will sit in D state until unlocked, but time will continue as expected. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
