On Mon, 16 Nov 2020 18:47:22 +0100, Pierre-Louis Bossart wrote:
Explicit 'ifs' asking whether we're dealing with SOF or other solution is at best a code smell. I believe this is unnecessary complexity added to the code especially once you realize user needs to play with module parameters to switch between solutions. If we assume user is able to play with module parameters then why not simply make use of blacklist mechanism?
Been there, done that. We don't want to use either denylist of kernel parameters.
denylists create confusion for users, it's an endless stream of false errors and time lost in bug reports.
The use of the kernel parameter is ONLY for expert users who want to tinker with the system or debug issues, the average user should not have to play with either denylists or kernel parameters.
I guess Cezary mean the modprobe blacklist? This was used in the early stage of ASoC Skylake driver development, but in the end, it's more cumbersome because user needs to change multiple places. The single module parameter was easier to handle.
And last but not least: intel-dsp-config is (as already stated) a mean for solving the HDA-runtime-driver-selection problem. Mixing it with ACPI devices is another layer of confusion.
Why? Who said it was PCI only? We already take care of DMIC, SoundWire, Google Chromebooks, open platforms, why not ACPI? It's just one API to be used when more than one driver can register to the same device.
Well, currently intel-dsp-config sits in sound/hda, which isn't really intuitive. Though, Intel driver file paths are already fairly scattered, so it doesn't matter too much :)
I don't mind to move it to another directory, but which one...? x86 might match, but shuffling the place won't help for maintenance.
I personally find this move good, at least it makes things easier for distros. There are small details like the above, but technically seen, I see no big problem.
thanks,
Takashi