On 19/10/2022 14:58, Cezary Rojewski wrote: > On 2022-10-19 1:16 PM, Péter Ujfalusi wrote: >> at the moment: >> # ls -al /lib/firmware/intel/ | wc -l >> 108 >> >> We might have 2 sets of binaries per platform, one using product key, >> other using community key. >> >> If we dump everything in one directory (/lib/firmware/intel/), things >> will go out of hand pretty easily which can be somehow handled with >> complex file naming. This is only for the basefw, then we have the >> libraries (however they are sourced) with again two sets of keys, >> platforms. >> >> Surely it can be done, but historically SOF prefers to use directories >> instead of pre/mid/post-fixing patterns of file names. > > The concern is understandable. We haven't said that firmware files > should be put directly under intel/ though. > >> Also note that SOF is looking for a module UUID when trying to load a >> library we don't track arbitrary file names (see cover letter). > > Neither 'dsp_fw_' nor 'dsp_lib_' prefix is arbitrary. Sure, but if you add things like platform, key type... > A library may > consist of more than one module, each with unique UUID. In general, > 'library' does not equal 'module'. See the cover letter. The SOF implementation is to use the module UUID as a file name when it comes to libraries. It is not our intention to maintain a UUID to filename mapping in kernel to looks for a specific module (which might be part of a bundle-library). We have clear instructions for external library producers on how to handle this and so far it holds up in scenarios we can think of. Surely, this is not the only way to implement it, but this is closer to the SOF way. > Now, when speaking of modules, > firmware-loading procedure that searches for file with certain UUID in > its name is part of other drivers too and I haven't questioned that - > it's perfectly fine and we're making use of the method ourselves. Glad to hear that it is not only me/us to take this path ;) -- Péter
