From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935961AbcIFVL1 (ORCPT ); Tue, 6 Sep 2016 17:11:27 -0400 Received: from mail-pf0-f176.google.com ([209.85.192.176]:34293 "EHLO mail-pf0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753827AbcIFVLX (ORCPT ); Tue, 6 Sep 2016 17:11:23 -0400 Date: Tue, 6 Sep 2016 14:11:17 -0700 From: Bjorn Andersson To: Linus Torvalds Cc: "Luis R. Rodriguez" , Daniel Vetter , Mimi Zohar , Felix Fietkau , David Woodhouse , Roman Pen , Ming Lei , Andrew Morton , Michal Marek , Greg KH , Linux Kernel Mailing List , Vikram Mulukutla , Stephen Boyd , Mark Brown , Takashi Iwai , Johannes Berg , Christian Lamparter , Hauke Mehrtens , Josh Boyer , Dmitry Torokhov , Jiri Slaby , Andy Lutomirski , Wu Fengguang , Richard Purdie , Jeff Mahoney , Jacek Anaszewski , Abhay_Salunke@dell.com, Julia Lawall , Gilles.Muller@lip6.fr, nicolas.palix@imag.fr, Tom Gundersen , Kay Sievers , David Howells , Alessandro Rubini , Kevin Cernekee , Kees Cook , Jonathan Corbet , Thierry Martinez , cocci@systeme.lip6.fr, linux-serial , "open list:DOCUMENTATION" , linuxppc-dev Subject: Re: [RFC] fs: add userspace critical mounts event support Message-ID: <20160906211117.GE15161@tuxbot> References: <1466117661-22075-3-git-send-email-mcgrof@kernel.org> <20160824203901.GT3296@wotan.suse.de> <20160825194133.GC3296@wotan.suse.de> <20160902235916.GO3296@wotan.suse.de> <20160903002014.GP3296@wotan.suse.de> <20160906174630.GB15161@tuxbot> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 06 Sep 11:32 PDT 2016, Linus Torvalds wrote: > On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson > wrote: > > > > Linus, I reversed the order of your questions/answers to fit my answer > > better. > > Nobody has actually answered the "why don't we just tie the firmware > and module together" question. > The answer to this depends on the details of the suggestion; but generally there's a much stronger bond between the kernel and the driver than between the driver and the firmware in my cases. E.g. we have a single remoteproc driver loading and controlling the Hexagon DSP found in several Qualcomm platforms, so a single kernel binary could (practically) load hundreds of variants of the firmware. Both the kernel binary and the firmware in this example are side-loaded onto the device during development - independently of each other, as they are developed by different teams (or maybe even different companies). I assume that you're not suggesting to actually tie the module together, as that would be practically difficult and a waste of resources. Which leaves us with the suggestion that we should store the kernel module with the firmware file, which is just infeasible from a few practical reasons - again mostly related to the development flow and how the files are contained on the devices. > Really. If the driver doesn't work without the firmware, then why the > hell is it separated from it in the first place? > In several cases we have a single remoteproc driver controlling several different co-processors. Further more with the aspiration of being able to run the same kernel binary (including modules) on more than one product this is simply not feasible. As I said above, beyond development there are hundreds of variants of these firmware files in products - each weighting in at 10-50MB. The firmware loading part (remoteproc) doesn't care about these differences and the functional drivers attaching to the services provided by the firmware can handle the differences between them. > The hack is a hack, and it just sounds *stupid*. > This I totally agree with. Regards, Bjorn