On 2020-11-18 8:49 AM, Takashi Iwai wrote:
On Tue, 17 Nov 2020 23:13:13 +0100, Rojewski, Cezary wrote:
...
Thanks for joining the discussion, Takashi.
If the switch of solution for atom-based products is imminent, why add code which becomes redundant soon after?
Yes, indeed I meant the modprobe blacklisting as it solves the problem without addition of any code. Doubt alsa-driver entries are scattered in /etc/modprobe.d/ so switching between one solution to another via blacklist becomes as easy as changing 'options intel-dsp-config
<param>==<value>' entry.
Ideally blacklist would work well, but practically it can be more problematic. When you *switch* between multiple drivers via blacklist, you'll have to mask one of them while keeping another untouched, so either: blacklist A or blacklist B
Now, imagine that distro sets "blacklist A" to choose B as the default. What user has to do? They have to modify "blacklist A" line with "blacklist B". But it can't be done with an additional modprobe.d/*.config file; otherwise this blacklist remains. It means they have to scratch the system configuration file itself -- which might be again overridden by a package update or whatever.
This will be more complex if there are more than three choices, of course.
Admittedly, the situation with the system config file be same for module option if distro sets the option in modprobe.d/*, too. But, there is another difference: the default option value can be set in the kernel code, while the blacklist approach is to let all open and choose via blacklist. IOW, devs have some control for choosing the default value for the module option but for blacklist they are all done by user-space side.
I agree, module param is ultimately easier to handle than denylist. The reason I had mentioned that is: if user is capable of changing value for module param, then we might as well assume he or she is the experienced one and playing with denylist isn't a problem either.
And hopefully we don't reach a point in time where again 3 flavours for atom-based products are available : )
In regard to catpt, solution is even simpler: just remove sound/soc/sof/intel/bdw.c as that code is not valid & recommended anyway and linux kernel is not place for such. There shouldn't be really any options for not recommended stuff. Leave the selection explicit.
...
Well, if non-Intel guys see the localization of code counter-intuitive then how about those who play with it daily..
I play it and maintain it daily, that's why I find unintuitive :) I guess most users don't notice the file path, as the module loading or option is done only by the module name.
Perhaps I misworded my previous statement. What I meant is: you don't have access to all the stuff we - Intel employees - have like specs, firmware documentation, hardware specifics and yet you see the problem. And this tells me there's still a lot to be done.
The new "sof-parent" checks won't make maintaining any easier and I believe there are easier solutions as written above.
If you find a good way to overcome the disadvantage, that's great. Let's see.
Well, the disadvantage is: weight of maintenance of newly added code. All in all, as mentioned in other reply, we could settle with selection mechanism for atom while leaving hsw/bdw out of it.
Czarek