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

[Takashi Iwai]

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