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

[Takashi Iwai]

On Fri, 09 Apr 2021 10:34:03 +0200,
Jaroslav Kysela wrote:
> 
> Dne 09. 04. 21 v 9:39 Takashi Iwai napsal(a):
> > On Thu, 08 Apr 2021 20:51:41 +0200,
> > Pierre-Louis Bossart wrote:
> >>
> >>
> >>
> >>>>> 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.
> > 
> > Couldn't the driver probe the firmware files with some device-specific
> > string suffix at first?  e.g. the driver can issue request_firmware()
> > with $base_file-$dmi_board at first, then falls back to the generic
> > $base_file.  A similar method was already used in Broadcom WiFi
> > driver.
> > 
> > Also, the driver may do request_firmware() with a fixed path for the
> > custom firmware at first (e.g. "intel/sof-tplg-custom"); then a system
> > integrator may set up a specific configuration even that doesn't match
> > with DMI or whatever identifier.
> 
> And when we have two firmware files which differs just by functionality
> requested by user? Although your method will work, I won't close the
> possibility to configure everything in udev rather using a hard coded fw load
> scheme only.

That can be achieved via a module option as Curtis's example, no?

That comes to a question at which stage you want to re-configure the
stuff.  I suppose that, if the system has been set up, then the
firmware cannot be changed on the fly; usually you have to rewind the
stuff and re-initialize from the beginning of the driver binding.
This corresponds to the device unbind and re-bind procedure
(equivalent with hot-unplug and hot-replug).  Then you can put your
change (e.g. set up module option or a dedicated firmware file)
between the unbind and rebind step.

If we make the driver setup as staged (i.e. waiting for the setup via
sysfs before moving to the actual firmware loading), a concern with
that is the fragility and complexity.  If the sysfs set up via sysfs
missed or went wrong, all goes south.


Takashi