In some places, the code was already using that, so only the header file needed
to be adjusted.
We use 'nl' for the sd_netlink* when it's passed in as input. I was considering
renaming to 'netlink', but that'd add a lot of verbosity and also we have
'sd_journal *j' in sd-journal, so the short name matches in style.
Follow-up for 4c733d3046.
Finding a suitable limit that would fit any use cases out there is pretty hard
and since /dev is only writeable by root anyway, let's simply drop the limit.
Instead of always asking for passphrase, if the device has LUKS2 header check:
- If only regular passphrases are registered, ask for passphrase.
- If only recovery keys are registered, ask for recovery key.
- If both regular passphrases and recovery keys are registered, ask for
passphrase or recovery key.
udev: hwdb: Add orientation quirk for base-mounted accelerometers on Chromebooks
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
The cros-ec-accel devices report their mounting location by the 'label'
sysfs file only since Linux v6.0. With earlier kernels, a nonstandard
'location' file reports this, but slightly differently (lid instead of
display) [1].
Add udev rules to import the correct hwdb entries based on this
'location' file for cros-ec-accel devices, so that the base-mounted
accel matrix has the correct value for older kernels as well.
[1] https://kernel.org/doc/Documentation/ABI/testing/sysfs-bus-iio-cros-ec
The base-mounted accelerometer on Chromebooks return values same as the
display when the lid angle is 180 degrees, instead of when the lid is
closed. To match userspace expectations we must further rotate the
existing accelerometer mounting matrix by 180 degrees around the X axis:
[[-1, 0, 0], [[ 1, 0, 0], [[-1, 0, 0],
[ 0, -1, 0], X [ 0, -1, 0], = [ 0, 1, 0],
[ 0, 0, -1]] [ 0, 0, -1]] [ 0, 0, 1]]
A previous commit lets us distinguish between the two cros-ec-accel
devices on these boards by their 'label' sysfs file. Add hwdb entries
that make base-mounted accelerometers use this correct matrix, and
display-mounted ones use the existing one.
Note that the cros-ec-accel drivers use 'label' only since Linux v6.0.
The old match strings are not removed to support older kernels, even
though they are only correct for the display-mounted sensor.
The IIO subsystem exposes a 'label' sysfs file to help userspace better
identify its devices [1]. Standardized labels include the sensor type
along with its location, including 'accel-base' and 'accel-display'.
Most Chrome OS boards have two accelerometers that are indistinguishable
except for this label (or a 'location' sysfs file before Linux v6.0),
and need different mounting matrix corrections based on their location.
Add a udev rule that matches hwdb entries using this label, so we can
correct both accelerometers on these devices with hwdb entries. The
existing rules and hwdb entries are not modified to keep potential
out-of-tree entries working, but new entries in this form will override
existing ones. Also add currently standardized labels to parse-hwdb.py.
[1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-iio
On reconfiguring an interface, the new setting may not enable IPv4ACD
for an existing address anymore. Hence, we need to unref it. Otherwise,
newly requested addresses may never be ready for (re-)configuring.
Previously, when a DHCP address is renewed and if the IPv4ACD for the
address is enabled, the address will never drop the probing flag, thus
the lifetime of the address will never be updated.
This drops NETWORK_CONFIG_STATE_PROBING, and the IPv4ACD status is
managed another bit, Address.acd_bound. And, the flag is updated only
when the IPv4ACD announced the address or detects conflict.
libdevmapper/device mapper driver can return semi-random failures when
opening verity devices, and we have fallback code to deal with it.
But the test was not expecting the fallback path, so it became unreliable.
Fixes https://github.com/systemd/systemd/issues/23866
For whatever reason, nowadays we add entries that are quite long, so
we were using line continuation for most of new entries. This is hard
to read and edit. So let's just make the table wide enough to accomodate
all the names without line splits.
Acquiring random data from the TPM is not precisely quick, let's speed
things up by doing this at most once per boot. For that, let's maintain
a flag file in /run/.
Previously, true by validate() means several configs are outdated and we
need to reload configs. That's not intuitive for me. Let's rename the
functions.
If a system has multiple graphics cards, then we cannot associate
platform backlight devices to backlight devices under PCI bus.
Previously, in such case, vaidate_device() for a raw backlight device
might erroneously detect a platform device and return false. So, users
could not save/load backlight level.
This makes validate_device() give up to associate platform devices on
non-PCI bus with raw backlight devices. That may cause unwanted
backlight level save or restore by systemd-backlight@.service, but users
can workaround that by masking specific instances of the service.
Closes#24223.
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Franck Bui
Antonio Alvarez Feijoo
Yu Watanabe
Alper Nebi Yasak
Frantisek Sumsal
Daan De Meyer
Luca Boccassi