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.
Takashi
