[PATCH] ALSA: core - add more card sysfs entries

[Jaroslav Kysela]

Dne 08. 04. 21 v 20:51 Pierre-Louis Bossart napsal(a):
> 
> 
>>>> When we have a common standard layer for the plug-and-play handling (udev), we
>>>> should concentrate to allow changing / refining of this information there.
>>>> Those strings are not used for anything else than the user space. So from my
>>>> view, there's no reason to create another mechanism to handle the overrides.
>>>> It should be a safe, fast, flexible and_optional_  solution. The udev can
>>>> alter the sysfs attributes directly without any hassle with the file
>>>> modifications or looking for another way to pass / store this information
>>>> somewhere.
>>>
>>> There's one part where I am lost.
>>>
>>> The initial idea of udev what to modify kernel parameters to pick a
>>> different path for firmware/topology before probing the PCI driver. At
>>
>> This may be a problematic point. The kernel cmdline cannot be modified from
>> udev (as far as I know). The module parameters can be set using modprobe's
>> config files or when loaded with sysfs attributes (/sys/module/*/parameters).
>> Eventually, you can call the modprobe command with custom module parameters
>> when the appropriate MODALIAS is probed.
>>
>> Perhaps, I'm missing something here, too. Some example udev rules may help.
> 
> see the example shared by Curtis
> 
> SUBSYSTEM=="pci", ATTR{vendor}=="0x8086", ATTR{device}=="0xa0c8", 
> ATTR{class}=="0x040100", ATTRS{[dmi/id]board_name}=="Eldrid", 
> RUN+="/sbin/modprobe snd_sof_pci tplg_path=intel/sof-tplg/pdm1"
> 
> Those 'path' parameters would have to be set prior to creating the card, 
> making them writable via sysfs would not work, the firmware and topology 
> are already loaded and changing the paths would have no effect.

Yes, it's something what I suggested. It's own modprobe call which modifies the module parameters.

>>> that point there is no card and no sysfs attributes just yet, they will
>>> be added at a later point during the probe itself.
>>>
>>> So are we talking about a second set of rules that would be applied when
>>> the card is created?
>>
>> Yes, I'm talking about rules which depends on the sound driver specific sysfs
>> attributes (you can match the modified /sys/module/*/parameters here).
> 
> you lost me with 'match the modified parameters' wording. who matches 
> and who modifies those parameters?

You can probably add something like this to the sound-card.rules:

SUBSYSTEMS=="pci",ATTR{device/driver/module}=="snd_soc_sof_sdw",
  ATTR{device/driver/module/../snd_sof_pci/parameters/tplg_path}=="intel/sof-tplg/pdm1",
  DO_SOMETHING_HERE

DO_SOMETHING_HERE may be ATTR{longname}="My Long Name" for example when my change is accepted.

				Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.