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. Jaroslav -- Jaroslav Kysela <perex@xxxxxxxx> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.