diff --git a/drivers/soundwire/sysfs_slave.c b/drivers/soundwire/sysfs_slave.c index 83e3f6cc3250..3723333a5c2b 100644 --- a/drivers/soundwire/sysfs_slave.c +++ b/drivers/soundwire/sysfs_slave.c @@ -174,6 +174,16 @@ static ssize_t words_show(struct device *dev, } static DEVICE_ATTR_RO(words);
+static umode_t dp0_is_visible(struct kobject *kobj, struct attribute *attr,
int n)+{
- struct sdw_slave *slave = dev_to_sdw_dev(kobj_to_dev(kobj));
- if (slave->prop.dp0_prop)
return attr->mode;- return 0;
+}
This changes the results slightly by creating an empty 'dp0' directory with no attributes inside.
Before:
[root@fedora ~]# cd /sys/bus/soundwire/devices/sdw:3:025d:0714:01 [root@fedora sdw:3:025d:0714:01]# ls dp0 ls: cannot access 'dp0': No such file or directory
After: [root@fedora sdw:3:025d:0714:01]# ls dp0
That should be fine, tools should just be looking for the attributes, not the existance of a directory, right?
The idea what that we would only expose ports that actually exist. That's helpful information anyone with a basic knowledge of the SoundWire specification would understand.
Is "dp0" a port? If so, why isn't it a real device?
The SoundWire spec defines the concept of 'data port'. The valid ranges are 1..14, but in all existing devices the number of data ports is way smaller, typically 2 to 4. Data ports (DPn) are source or sink, and there's no firm rule that data ports needs to be contiguous.
DP0 is a 'special case' where the data transport is used for control information, e.g. programming large set of registers or firmware download. DP0 is completely optional in hardware, and not handled in Linux for now.
DP0 and DPn expose low-level transport registers, which define how the contents of a FIFO will be written or read from the bus. Think of it as a generalization of the concept of TDM slots, where instead of having a fixed slot per frame the slot position/repetition/runlength can be programmed.
The data ports could be as simple as 1-bit PDM, or support 8ch PCM 24-bits. That's the sort of information reported in attributes.
The attributes are really details that few people/applications would understand, and unfortunately the information reported in DSDT is more often than not complete garbage.
I don't understand what DSDT is, or how it is relevant here :(
Platform firmware typically exposes the presence of ports and the details since there are no descriptors in hardware. The DSDT in ACPI exposes _DSD properties under the SoundWire device scope, which are compatible with DT properties. In other words, what the driver exposes in sysfs is just a mirror of what was reported by platform firmware - unless it was overridden by a driver.