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
