On Mon, 30 May 2022 12:53:29 +0200, Charles Keepax wrote: > > On Mon, May 30, 2022 at 12:45:08PM +0200, Takashi Iwai wrote: > > On Mon, 30 May 2022 12:34:15 +0200, > > Charles Keepax wrote: > > Well, if an ALSA control can trigger the firmware loading, that's > > already fragile. A firmware loading is a heavy task, which should > > happen only at probing and/or resuming in general. Do we have other > > drivers doing the f/w loading triggered by a kctl...? > > > > > I guess we could look at adding locked versions of the add > > > control functions as well if that might be preferred? > > > > If the patterns of additional kctls (specific for firmware?) are > > fixed, we may create all such kctls beforehand and let them inactive > > unless the corresponding firmware is really loaded, too. > > > > I am afraid we do, basically all the Wolfson/Cirrus audio devices > allow you to select the firmware through a kctl. The patterns of > controls are specific to the firmwares, so we can't really create > them ahead of time. One could maybe look at changing when the > firmwares are loaded, such as attempting to load all possible > firmwares on boot or something but its a fairly sizable change > that isn't without some side effects. The call of request_firmawre() itself can be pretty lengthy (e.g. it may hold until user-space process uploads the firmware if the fallback mode is enabled), and it implies that the request_firmware() call doesn't fit well as the operation to be done in a kctl put callback. So, even if we accept the firmware loading behavior via kctl as-is, the whole procedure should be async in work instead; namely, not only kctl creation/deletion but both request_firmware() + post-process should be done in the work. And yet moreover, we'll need to consider some way for protecting against DoS-like behavior by frequent kctl changes. thanks, Takashi
