Re: [PATCH 2/6] ASoC: SOF: Introduce descriptors for SOF client

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




As you are creating new sysfs directories, you should have
some
documentation for them :(
Hi Greg,

We are not adding any sysfs entries in this series.

You added directories in sysfs, right?
Hi Greg,

We are not adding any sysfs directories.

Really?  Then what does creating these new devices do in sysfs?  If
nothing, then why are they being used at all?  :)

The only change in the /sys directory will be the new ancillary
devices created in the /sys/bus/ancillary/devices directory ie
snd_sof_client.ipc_test.0 and snd_sof_client.ipc_test.1.

That is what I was referring to.

In the following patches, we're adding debugfs entries for the ipc
test clients but no other sysfs changes.

Is it required to add documentation for these as well?

Why would you not document them?  If you don't do anything with these
devices, then why even use them?  debugfs does not require sysfs
entries, so I fail to see the need for using this api at all here...
Hi Greg,

Pardon my ignorance here a bit. Typically, when registering platform
devices, we've not added any documentation to highlight how they are
used. Of course thats no excuse for not doing this right.

But just to clarify so that we can fix this properly in the next
version, are we expected to add documentation for the directories added
in the /sys/bus (ie /sys/bus/ancillary, /sys/bus/ancillary/devices,
/sys/bus/ancillary/drivers etc) and also for the devices and drivers
added by the SOF driver?

You are using a brand-new interface, which is designed to represent
things in the driver model and sysfs properly, and yet your usage
doesn't actually take advantage of the driver model or sysfs at all?

That implies to me that you are using this incorrectly.

We are taking advantage of 'standard' sysfs capabilities, e.g. we get a power/ directory and can disable pm_runtime if we chose to do so.

But the point is that for now we haven't added domain specific properties with attributes.

For example, I noodled with this code last week to replace the platform devices with ancillary devices in the Intel SoundWire code, and I get this in sysfs:

root@plb:/sys/bus/ancillary/devices/soundwire_intel.link.0# ls -l
total 0
lrwxrwxrwx 1 root root 0 Oct 2 15:48 driver -> ../../../../bus/ancillary/drivers/intel-sdw lrwxrwxrwx 1 root root 0 Oct 5 10:12 firmware_node -> ../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:63/PRP00001:00
drwxr-xr-x 2 root root    0 Oct  5 10:12 power
drwxr-xr-x 5 root root    0 Oct  2 15:48 sdw-master-0
lrwxrwxrwx 1 root root 0 Oct 2 15:48 subsystem -> ../../../../bus/ancillary
-rw-r--r-- 1 root root 4096 Oct  2 15:48 uevent

What would you want us to document here?



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux