On Fri, 09 Apr 2021 17:55:38 +0200, Pierre-Louis Bossart wrote: > > > >>> 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 > >> > > > > I've slept on it and now I think I see what you are trying to do. > > > > 1. Load FW dependent on platform/user settings > > 2. Load appropriate topology for FW > > 3. Have UCM for the FEs and controls exposed by driver > > > > > > As for 1. I would say that FW should be loaded from one location > > if there is some platform that requires special FW just add quirks, > > like it is done with every other driver, and if someone wants to > > build their own special FW, they just replace it. We can't possibly > > support hundreds of possible FW modifications if users want them by > > putting them in separate files. Alternatively allow override via > > kernel parameters. > > Overriding FW files via udev would only make sense to me if it was > > possible to upload new FW at runtime. > > No, replacing firmware files is not viable. > > Let me give you a practical example. In the course of SOF development, > we routinely copy new test firmware+topology in the location of > distribution-managed files. It's classic that when there is a > distribution update in the background to install the latest SOF > release, our test files are overwritten and it's not usual for > developers to lose time trying to figure out why the functionality > changed. We do need to have multiple paths and NEVER override what is > provided by the distributions. it's the moral equivalent of /usr/bin > v. /usr/local/bin. Use /lib/firmware/updates/*. That precedes over the standard path /lib/firmware/*. (Also /lib/firmware/updates/$VERSION has even higher priority.) Takashi
