TC Applied Technologies designed the series of ASIC for audio and music
data transmission in several types of communication bus. It's named as
Digital Interface Communication Engine (DICE). Four ASICs are known in
the series for IEEE 1394 bus; Dice II, TCD2210 (Dice Jr.), TCD2220 (Dice
Mini), and TCD3070 (DiceIII).
The content of configuration ROM in products based on DICE ASICs is
known against specification defined by 1394 Trading Association.
This commit adds database entries for models without any customization by
vendors. In TCAT specification, The value of GUID field is split to four
parts; 24-bit OUI, 8-bit category, 10-bit product ID, and 22-bit serial
number in the order. In the specification, the value of category field is
fixed to 0x04. The root directory includes leaf entries for vendor and
model names. Although the specifier_id field in unit directory differs
depending on vendors, the version field in unit directory is fixed to
0x000001. ALSA dice driver supports them, but expects userspace
application to control them.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Once Oxford Semiconductor designed FW970 and FW971 ASICs as Multi-Channel
Isochronous Streaming FireWire Audio Controller. Some vendors used them
in their products for audio and music units.
The content of configuration ROM has standard layout of 1394 Trading
Association with an additional Dependent Information directory.
This commit adds database entries for the known models. ALSA oxfw
driver supports them, but expects userspace application to control them.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Echo Audio Corporation designed Fireworks board module. The module is used
by several vendors for models.
The content of configuration ROM in the models s some quirks and against
standard of 1394 Trading Association.
This commit adds database entries for the model. ALSA fireworks driver
supports them but expects userspace application to control them.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
ArchWave AG, formerly known as BridgeCo. AG, designed DM1000, DM1100, and
DM1500 ASICs for BridgeCo. Enhancement BreakOut Box (BeBoB) solution.
They were used for many models shipped by many vendors.
The content of configuration ROM has standard layout of 1394 Trading
Association with an additional Dependent Information directory.
This commit adds database entries for the known models. ALSA bebob
driver supports them, but expects userspace application to control them.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Although in IEEE 1394 unit function list I have a plan to use slash sign
in name of property, current implementation of parser doesn't allow it.
When parsing current entries in database excluded from parser testing, we
can find usage of slash sign in name of property.
This commit adds slash sign in allow list of the parser for my
convenience.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
In added IEEE 1394 unit function list, I use custom key to detect unit
entries in node context. Although the list is not widely used in the most
of systemd users, I would like to add parser grammar for testing, by
borrowing a bit time in builders.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
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>
The s390 PCI driver assigns the hotplug slot name from the
function_id attribute of the PCI device using a 8 char hexadecimal
format to match the underlying firmware/hypervisor notation.
Further, there's always a one-to-one mapping between a PCI
function and a hotplug slot, as individual functions can
hot plugged even for multi-function devices.
As the generic matching code will always try to parse the slot
name in /sys/bus/pci/slots as a positive decimal number, either
a wrong value might be produced for ID_NET_NAME_SLOT if
the slot name consists of decimal numbers only, or none at all
if a character in the range from 'a' to 'f' is encountered.
Additionally, the generic code assumes that two interfaces
share a hotplug slot, if they differ only in the function part
of the PCI address. E.g., for an interface with the PCI address
dddd:bb:aa.f, it will match the device to the first slot with
an address dddd:bb:aa. As more than one slot may have this address
for the s390 PCI driver, the wrong slot may be selected.
To resolve this we're adding a new naming schema version with the
flag NAMING_SLOT_FUNCTION_ID, which enables the correct matching
of hotplug slots if the device has an attribute named function_id.
The ID_NET_NAME_SLOT property will only be produced if there's
a file /sys/bus/pci/slots/<slotname> where <slotname> matches
the value of /sys/bus/pci/devices/.../function_id in 8 char
hex notation.
Fixes#19016
See also #19078
When this test is run in mkosi, the previously tested cgroup that we write
xattrs into and the root cgroup are the same.
Since the root cgroup is a live cgroup anyways (vs. the test cgroups which are
remade each time) let's generate the expected preference values from reading
the xattrs instead of assuming it will be NONE.
Fixes this error I got building on F33:
/usr/bin/ld: test-random-util.p/src_test_test-random-util.c.o: undefined
reference to symbol 'sqrt@@GLIBC_2.2.5'
/usr/bin/ld: /usr/lib64/libm.so.6: error adding symbols: DSO missing
from command line
Follow-up for 7117842657.
sd_device_monitor_filter_add_match_subsystem_devtype() now returns 1 to signify
that something was done, and 0 to signify that nothing was done, but
udev_monitor_filter_add_match_subsystem_devtype() needs to return 0 as documented.
udev_monitor_filter_add_match_tag() is adjusted to match.
This makes gdm start successfully here again.
Before, it would just not boot, with nothing very obvious in the logs:
gdm[1756]: Gdm: GdmDisplay: Session never registered, failing
Replaces #19171.
The issue was introduced in the refactoring in 775ae35403.
We would pass an initialized value to a helper function. We would only *use*
it if it was initialized. But the mere passing of an unitialized variable is
UB, so let's not do that. This silences a gcc warning.
The old code was just fine, but gcc doesn't understand that max_brightness is
initialized. Let's rework it a bit to move some logic to the main function. Now
get_max_brightness() just retrieves and parses the attribute, and the main
function decides what to do with it.
gcc was very unhappy for some reason:
[988/1664] Compiling C object systemd-oomd.p/src_oom_oomd.c.o
In file included from ../src/basic/path-util.h:10,
from ../src/shared/pretty-print.c:14,
from ../src/oom/oomd.c:15:
../src/shared/pretty-print.c: In function ‘conf_files_cat’:
../src/basic/strv.h:123:32: warning: ‘prefixes’ may be used uninitialized [-Wmaybe-uninitialized]
123 | for ((s) = (l); (s) && *(s); (s)++)
| ^
In file included from ../src/oom/oomd.c:15:
../src/shared/pretty-print.c:283:16: note: ‘prefixes’ was declared here
283 | char **prefixes, **prefix;
| ^~~~~~~~
../src/shared/pretty-print.c:305:12: warning: ‘is_collection’ may be used uninitialized in this function [-Wmaybe-uninitialized]
305 | if (!is_collection) {
| ^
../src/shared/pretty-print.c:301:13: warning: ‘extension’ may be used uninitialized in this function [-Wmaybe-uninitialized]
301 | r = conf_files_list_strv(&files, extension, root, 0, (const char* const*) dirs);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Maybe this is caused by the statis char** variables?
[1/429] Compiling C object src/shared/libsystemd-shared-248.a.p/bus-message-util.c.o
../src/shared/bus-message-util.c: In function ‘bus_message_read_dns_servers’:
../src/shared/bus-message-util.c:165:21: warning: ‘family’ may be used uninitialized in this function [-Wmaybe-uninitialized]
165 | r = in_addr_full_new(family, &a, port, 0, server_name, dns + n);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/shared/bus-message-util.c:165:21: warning: ‘port’ may be used uninitialized in this function [-Wmaybe-uninitialized]
../src/shared/bus-message-util.c:165:21: warning: ‘server_name’ may be used uninitialized in this function [-Wmaybe-uninitialized]
The warning would be there despite all the asserts in bus_error_setfv() and
sd_bus_error_set(). So let's add an explicit assert.
[2/3] Compiling C object test-capability.p/src_test_test-capability.c.o
../src/test/test-capability.c: In function ‘main’:
../src/test/test-capability.c:270:12: warning: ‘run_ambient’ may be used uninitialized in this function [-Wmaybe-uninitialized]
270 | if (run_ambient)
| ^
gcc-11.0.1-0.3.fc34.x86_64
[91/180] Compiling C object libsystemd.a.p/src_libsystemd_sd-event_sd-event.c.o
In file included from ../src/basic/macro.h:12,
from ../src/basic/alloc-util.h:9,
from ../src/libsystemd/sd-event/sd-event.c:11:
../src/libsystemd/sd-event/sd-event.c: In function ‘sd_event_wait’:
../src/fundamental/macro-fundamental.h:86:63: warning: ‘child_min_priority’ may be used uninitialized in this function [-Wmaybe-uninitialized]
86 | UNIQ_T(A, aq) < UNIQ_T(B, bq) ? UNIQ_T(A, aq) : UNIQ_T(B, bq); \
| ^
../src/libsystemd/sd-event/sd-event.c:3983:45: note: ‘child_min_priority’ was declared here
3983 | int64_t epoll_min_priority, child_min_priority;
| ^~~~~~~~~~~~~~~~~~
Alternative to #19159.
[59/655] Compiling C object src/shared/libsystemd-shared-248.a.p/varlink.c.o
../src/shared/varlink.c: In function ‘varlink_write’:
../src/shared/varlink.c:459:12: warning: ‘n’ may be used uninitialized in this function [-Wmaybe-uninitialized]
459 | if (n < 0) {
| ^
../src/shared/varlink.c: In function ‘varlink_process’:
../src/shared/varlink.c:541:12: warning: ‘n’ may be used uninitialized in this function [-Wmaybe-uninitialized]
541 | if (n < 0) {
| ^
../src/shared/varlink.c:486:17: note: ‘n’ was declared here
486 | ssize_t n;
| ^
It was one giant all of text in pseudo-random order. Let's split it into
paragraphs talk about one subject each.
And unfortunately, the description of what happens when the error is not
set was not correct. In general, various functions treat 0/NULL as
not-an-error, and return 0.
