On Fri 02 Sep 21:11 PDT 2016, Linus Torvalds wrote: Linus, I reversed the order of your questions/answers to fit my answer better. > On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > > > > Thoughts ? > What are the drivers that need this, and why can't those drivers just > be fixed to not do braindead things? > I have several cases where remoteproc drivers are used boot DSPs upon boot of the device, but the firmware files are way too big for being stored in initramfs and all consumers of the provided services are (semi-) probable as the remote processor is booted. I.e. we need some way to figure out when these files become available so we can bring these remote processors up. > It's basically the kernel giving up, and relying on user space to give > a single flag, and it's broken nasty crap. Worse, it's broken nasty > crap with a user interface, so we'll be stuck with it forever. Please > no. > There are several cases where there granularity of a single flag is not enough and we do already have a working mechanism for relying on user space to inform the kernel that firmware is available: CONFIG_FW_LOADER_USER_HELPER_FALLBACK Another available solution is, as you say, using kernel modules. But I really do not like the deployment issues that comes with kernel modules during development. (The firmware and remoteproc driver normally does not have the same flow through a development process) > > I really think this is a horrible hack. > I agree, but that said, I would appreciate a automagical mechanism that would relieve user space from having to signal to the kernel that the firmware partition has been mounted. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
