>>>>> 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? I don't see what adding another layer of hierarchy would bring. In their simplest configuration, there are 6 registers 8-bit exposed. And the port registers, when present, are accessed with a plain vanilla offset. > What uses these sysfs files today that would be confused about an empty > directory? That's a good question. I am not aware of any tools making use of those attributes. To a large degree, they are helpful only for debug and support, all these read-only attributes could be moved to debugfs. That could be a way to simplify everyone's life....
