This reverts commit 94cb45d57f.
This rule set up a duplicate import:
$ udevadm test /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.3
...
2-4.1.3: /usr/lib/udev/rules.d/40-libgphoto2.rules:9 Importing properties from results of builtin command 'usb_id'
2-4.1.3: /usr/lib/udev/rules.d/50-udev-default.rules:13 Skipping builtin 'usb_id' in IMPORT key
2-4.1.3: /usr/lib/udev/rules.d/50-udev-default.rules:13 Importing properties from results of builtin command 'hwdb --subsystem=usb'
2-4.1.3: hwdb modalias key: "usb:v17EFp3054:OneLink+ Giga"
2-4.1.3: /usr/lib/udev/rules.d/50-udev-default.rules:15 Importing properties from results of builtin command 'hwdb 'usb:v17efp3054''
2-4.1.3: No entry found from hwdb.
2-4.1.3: /usr/lib/udev/rules.d/50-udev-default.rules:15 Failed to run builtin 'hwdb 'usb:v17efp3054'': No data available
2-4.1.3: /usr/lib/udev/rules.d/50-udev-default.rules:52 MODE 0664
except that the existing one was done with uppercase digits and the full match pattern,
and the second one was done with lowercase digits.
With the previous commit we only have uppercase digits in our match patterns, so we can
drop the duplicate import. (Some other projects might have rules that used the lowercase
match patterns, and people might have some local rules that did that too. But the second
import was only added recently so I think it's better to rip off the bandaid quickly.)
Enable /dev/sgx_vepc access for the group 'sgx', which allows KVM-backed VMs
to host Intel Software Guard eXtension (SGX) enclaves. The upcoming QEMU
6.2 uses /dev/sgx_vepc to reserve portions of Enclave Page Cache (EPC) for
VMs. EPC is the reserved physical memory used for hosting enclaves.
When using "capture : true" in custom_target()s the mode of the source
file is not preserved when the generated file is not installed and so
needs to be tweaked manually. Switch from output capture to creating the
target file and copy the permissions from the input file.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
systemd-udevd.service listens to kernel uevents and is needed for device
units to be available.
systemd-udevd.service is misspelled as systemd-udev.service in a couple places.
Fixing typo.
The USB persist feature allows devices that can retain their state when
powered down to work across suspend/resume. This is in particular useful
for USB drives.
However, the persist feature can get in the way for devices that are
unable to retain their state when power is lost. An example of such
stateful devices are fingerprint readers where USB persist should be
disabled to ensure userspace can detect whether the USB device had a
power loss during system suspend.
This will initially be used by the libfprint autosuspend hwdb.
Closes: #20754
Import hwdb matches for USB devices (not interfaces) which don't usually
have a modalias so that it's possible to, for example, make them
available for unprivileged users.
ubifs volumes have a UUID and the built-in blkid is able to determine
it. The disk/by-uuid symlink isn't created because ubifs volumes are
not on block devices but on SUBSYSTEM="ubi" devices. See #20071.
Allow ubi subsystem devices to be processed by the persistent storage
rules too. The kernel device name matching already allows ubi* to pass.
The existing rules are sufficient to create the link.
The links look like other by-uuid symlinks, for example:
/dev/disk/by-uuid/9a136158-585b-4ba4-9b70-cbaf2cf78a1c -> ../../ubi0_1
Add quotes around use of $env{MODALIAS} in rules.d/80-drivers.rules. The
modalias can contain whitespace, for example when it is dynamically generated
using device or vendor IDs.
Quoting Documentation/driver-api/vfio.rst in Linux:
> note that /dev/vfio/vfio provides no capabilities on its own and is therefore
> expected to be set to mode 0666 by the system
In IEC 61883-1:1998, we can see some values for AV/C device with vendor
unique command set in IEC 61883-1:1998. Current udev rule handles it
for video. However it brings an issue that the functions in AV/C device
are not distinguished just by the content of configuration ROM.
In former commit, hardware database was added to describe function type
of unit in the node, then udev rules are added to utilize the database.
However, we have an request to obsolete existent udev rules by putting
enough entries to the database. It should be done carefully.
This commit adds entry into hardware database just for backward
compatibility. The entry can match to some node and unit unexpectedly.
Therefore this commit modifies existent entries to invalidate the effect
from added entry.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Typical node of AV/C device has standard content of configuration ROM.
This is defined in documentation of 1394 Trading Association.
* Configuration ROM for AV/C Devices 1.0 (Dec. 12, 2000, 1394 Trading
Association, TA Document 1999027)
However, it brings an issue that the functions in AV/C device are not
distinguished just by the content of configuration ROM.
In former commit, hardware database was added to describe function type
of unit in the node, then udev rules are added to utilize the database.
However, we have an request to obsolete existent udev rules by putting
enough entries to the database. It should be done carefully.
This commit adds entry into hardware database just for backward
compatibility. The entry can match to some node and unit unexpectedly.
Therefore this commit modifies existent entries to invalidate the effect
from added entry.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Point Grey Research, inc. shipped cameras to support IIDC, however some
of them are necessarily compliant to IIDC specification in terms of the
value of software version field in unit directory of configuration ROM.
This commit adds entries for them.
Reviewed-by: Damien Douxchamps <damien@douxchamps.net>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Instrumentation & Industrial Digital Camera (IIDC) specifications are
defined by 1394 Trading Association for camera device in IEEE 1394 bus.
IIDC2 specifications are defined by joint working group between Japan
Industrial Imaging Association (JIIA) and 1394 Trade Association as
bus-independent specification.
This commit adds entries for the specifications to remove existent udev
rules. Supported specifications are listed below:
* 1394-based Digital Camera Specification Version 1.04 (Aug. 9, 1996,
1394 Trading Association)
* 1394-based Digital Camera Specification Version 1.20 (Jul. 23, 1998,
1394 Trading Association)
* IIDC Digital Camera Control Specification Ver.1.30 (Jul. 25, 2000,
1394 Trading Association)
* IIDC Digital Camera Control Specification Ver.1.31 (Feb. 2, 2004,
1394 Trading Association, TA Document 2003017)
* IIDC Digital Camera Control Specification Ver.1.32 (Jul. 24, 2008,
1394 Trading Association, Document number 2007009)
* IIDC2 Digital Camera Control Specification Ver.1.0.0 (Jan 26th, 2012,
1394 Trading Association, TS2011001)
* IIDC2 Digital Camera Control Specification Ver.1.1.0 (May 19th, 2015,
1394 Trading Association, TS2015001)
Reviewed-by: Damien Douxchamps <damien@douxchamps.net>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Some interfaces require that the DHCPOFFER message is sent via broadcast
if they can't receive unicast messages before they've been configured
with an IP address.
E.g., s390 ccwgroup network interfaces operating in layer3 mode face
this limitation. This can prevent the interfaces from receiving an
IP address via DHCP, if the have been configured for layer3.
To allow DHCP over such interfaces, we're introducing a new device
property ID_NET_DHCP_BROADCAST which can be set for those.
The networkd DHCP client will check whether this property is set
for an interface, and if so will set the broadcast flag, unless
the network configuration for the interface has an explicit
RequestBroadcast setting.
Besides that, we're adding a udev rule to set this device property
for ccwgroup devices operating in layer3 mode, which is the case
if the ID_NET_DRIVER property is qeth_l3.
Supercedes #18829
Current udev rules configures group owner of firewire character device
to video group, corresponding to nodes in IEEE 1394 in below cases:
1.the node with any unit for any minor version of IIDC version 1
specification defined by 1394 Trading Association
2.the node with any unit for specification defined by Point Grey Research
3.the node with any unit for AV/C device v1.0 defined by 1394 Trading
Association
4.the node with any unit for vendor-unique protocol defined by 1394
Trading Association
Nevertheless, case 3 and 4 can cover the node with any unit for audio
function as well. In the cases, it's convenient to assign audio group.
Additionally, some nodes are known to have layout different from
the specification defined by 1394 Trading Association. In the case,
it's required to add rules specific to them.
Furthermore, some nodes have no fields for vendor name and model name in
configuration ROM. In the case, it's required to add entries to hardware
database for users convenience.
For the above reasons, this commit adds rules to use information in
hardware database for known units in IEEE 1394. One database entry
corresponds to one unit. Two types of key are used to match the unit;
customized key from node context, kernel modalias of unit context.
The entry has the type of function, at least. Supplementally, it has
vendor and model names.
For your information, below statements with Python pyparsing module are
expected to parse all of the custom key and module alias in the list:
```
subsystem_prefix = pp.Literal('ieee1394:').suppress()
hex_to_int = lambda a: int(a[0], 16)
node_prefix = pp.Literal('node:').suppress()
prefixed_lower_hex = pp.Combine(pp.Literal('0x') + pp.Word(pp.srange('[a-z0-9]'), exact=6)).setParseAction(hex_to_int)
ven_in_node = pp.dictOf(pp.Literal('ven'), prefixed_lower_hex)
mo_in_node = pp.dictOf(pp.Literal('mo'), prefixed_lower_hex)
unit_in_node = pp.Group(prefixed_lower_hex + pp.Literal(':').suppress() + prefixed_lower_hex)
units_in_node = pp.Group(pp.Literal('units') + pp.ZeroOrMore(pp.Literal('*')).suppress() + unit_in_node + pp.ZeroOrMore(pp.Literal('*')).suppress())
node_parser = subsystem_prefix + node_prefix + ven_in_node + pp.Optional(mo_in_node) + units_in_node
higher_hex = pp.Word(pp.srange('[A-Z0-9]'), exact=8).setParseAction(hex_to_int)
ven_in_unit = pp.dictOf(pp.Literal('ven'), higher_hex)
mo_literal_in_unit = pp.dictOf(pp.Literal('mo'), higher_hex)
mo_in_unit = pp.dictOf(pp.Literal('mo'), higher_hex ^ pp.Literal('*'))
sp_in_unit = pp.dictOf(pp.Literal('sp'), higher_hex)
ver_in_unit = pp.dictOf(pp.Literal('ver'), higher_hex)
unit_parser = subsystem_prefix + ven_in_unit + mo_in_unit + sp_in_unit + ver_in_unit
key_parser = node_parser ^ unit_parser
```
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Closes#18669.
This creates a "well known" for sgx_enclave ownership. By doing this here we
avoid the risk that various projects making use of the device will provide
similar-but-slightly-incompatible installation instructions, in particular
using different group names.
ACLs are actually a better approach to grant access to users, but not in all
cases, so we want to provide a standard group anyway.
Mode is 0o660, not 0o666 because this is very new code and distributions are
likely to not want to give full access to all users. This might change in the
future, but being conservative is a good default in the beginning.
Rules for /dev/sgx_provision will be provided by libsg-ae-pce:
https://github.com/intel/linux-sgx/issues/678.
