Hello Dragan and others, > I see and agree, but please note that other people highly disagree about > that being an issue at all. Thus, I'd suggest that you provide a > detailed > explanation of why and how that presents an issue that weakdeps solve. I think that the problem that I am trying to fix related to initramfs generation is understood. At least what I tried to explain at the beginning of this thread with my messages and the help of Lucas. But maybe you are right, so let me provide a more specific explanation. The only thing that I could repeat and/remark is that I am not modifying anything in the current kernel behavior, and specifically for this case (lan78xx) with a network driver and related phy modules: I am just trying to add a flag (and nothing else) to complete the information of the necessary modules to be collected by the tools that build the initramfs. And if this information about the necessary modules is not correctly collected, the kernel is not going to work from initramfs, Especially if the network drivers are not working (because the phy module is not found), some initial and necessary resources could not be available before and after initramfs stage, because unless the network driver is unloaded and loaded again after initramfs stage (then the phy modules would be available from rootfs), it is going to be in the same situation, that is, not correctly initialized and not working. Including in the initramfs all the phy modules is an option but I think it would be better to include only the necessary stuff (this is the default behavior for the tools that are used to build the initramfs). This is valid for embedded and not-embedded systems. If this patch, to only add the related flag of the network driver to inform about the possible phy modules, is rejected because a more general solution is preferred, I would like to dig into it, at least to know if it is possible to do better. Maybe Andrew in other part of the thread, after the interesting comments from Jakub, can help and provide some new (for me) inputs. > Regarding Lima and Panfrost, I agree that weakdeps are a better solution > than softdeps, but please see also harddeps. [1] I'd appreciate if > you'd provide your opinion about the proposed harddeps. > [1] > https://lore.kernel.org/linux-modules/04e0676b0e77c5eb69df6972f41d77cdf061265a.1721906745.git.dsimic@xxxxxxxxxxx/T/#u Ok, I will think more about it. After a quick first look I agree with Lucas, but let's go little by little (at least I don't have a lot of time before my holidays). Thanks Best regards José Ignacio
