modules: restore behaviour for non-LLEXT modules

[lyakh]

An earlier commit inadvertantly potentially changed behaviour of non-llext modules by imposing too strict a condition for calling modules_new(). Restore the original behaviour for those modules.

Fixes: 6b9b4c2 ("modules: don't re-load on each restart")

[pjdobrowolski]

We cannot allow register module with NULL pointer in md->ops or anything else. Untile module_adapter is not obsolete, llext need second separate condition.

[lyakh]

We cannot allow register module with NULL pointer in md->ops or anything else. Untile module_adapter is not obsolete, llext need second separate condition.

@pjdobrowolski could you please read the patch once again. It is not allowing any new NULL pointers. What it does for non-LLEXT modules is it extends the number of cases when modules_new() gets called, returning it to the state before my 6b9b4c2
If you check that commit, you'll see, that before it modules_new() was called always inside modules_init(). That commit changed it to call modules_new() only sometimes, namely the purpose of that change was to only call it when modules_init() was called for the first time. But this change should only affect LLEXT modules, non-LLEXT modules shouldn't be touched. So for non-LLEXT modules modules_new() should still be called every single time when modules_init() is entered. And this commit restores this behaviour. So I'm puzzled why this breaks loadable module QB tests.
In fact it isn't this PR that's breaking QB loadable module tests, please check #8932 QB result build 13704415 - you'll see the same failures

[pjdobrowolski]

Ok, I see but why do you extends modules type? Are llext modules compatible with IADK?

[softwarecki]

The module_data structure is unique for each module instance. You will not be able to tell whether this is the first loading of the module based on the value of any of its fields. I suggest following solution: #8939

[lyakh]

Ok, I see but why do you extends modules type? Are llext modules compatible with IADK?

@pjdobrowolski now sure what you mean by "extending the module type" - yes, LLEXT modules are different enough from other module types. No, they're in no way compatible with IADK.

[pjdobrowolski]

Ok, I think that to prevent future misunderstanding we should integrate @softwarecki refactor #8935 and after that you will have separe path of development only for llext modules.

[lgirdwood]

@lyakh@pjdobrowolski any update here ? I think some other PRs now applied, whats next ?