On Fri, Jul 29, 2022 at 10:52:28AM -0500, Pierre-Louis Bossart wrote:
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.
Why not make them a real device like we do for USB endpoints?
What uses these sysfs files today that would be confused about an empty directory?
thanks,
greg k-h