On Wed, Jul 10, 2024 at 04:22:12PM GMT, Dragan Simic wrote: > Hello Maxime, > > On 2024-07-10 09:13, Maxime Ripard wrote: > > On Tue, Jul 09, 2024 at 06:36:08PM GMT, Dragan Simic wrote: > > > > > > > As I already wrote earlier, and as the above-linked discussions > > > > > > > conclude, solving these issues doesn't belong to any specific driver. > > > > > > > It should be resolved within the kernel's firmware loading mechanism > > > > > > > instead, and no driver should be specific in that regard. > > > > > > > > > > > > IT would be good if it can be resolved within the kernel's firmware > > > > > > loading mechanism. > > > > > > > > > > ... we'll need this as a systemic solution. > > > > > > > > The general policy has been to put drivers that need a firmware as a > > > > module, and just never build them statically. > > > > > > I totally agree, but if Buildroot builds them statically and provides > > > no initial ramdisk, we need a better solution than having various > > > drivers > > > attempt to implement their own workarounds. > > > > Buildroot typically allows custom kernel configurations, so it's not > > really "enforcing" anything like another distro does. > > > > It is definitely targetted towards very stripped down systems, so I > > guess building the drivers statically is a natural choice, but it works > > fine with modules too. > > It all leads to a conclusion that we need better in-kernel support > for delayed firmware loading, instead of drivers implementing various > workarounds, for the layouts in which drivers are built statically > into the kernel image, but the required firmware blobs reside on the > root filesystem. > > I'll start working on it, hopefully today. :) I don't want to prevent you from trying, but be aware that similar attempts have been shut down repeatedly in the past. Maxime
Attachment:
signature.asc
Description: PGP signature
