Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753412AbdF0Tw4 (ORCPT ); Tue, 27 Jun 2017 15:52:56 -0400 Received: from mail-pf0-f179.google.com ([209.85.192.179]:36077 "EHLO mail-pf0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752814AbdF0Twr (ORCPT ); Tue, 27 Jun 2017 15:52:47 -0400 Date: Tue, 27 Jun 2017 12:52:39 -0700 From: Bjorn Andersson To: "Luis R. Rodriguez" Cc: Jakub Kicinski , Ming Lei , yi1.li@linux.intel.com, "AKASHI, Takahiro" , nbroeking@me.com, Greg Kroah-Hartman , mfuzzey@parkeon.com, ebiederm@xmission.com, Dmitry Torokhov , Daniel Wagner , David Woodhouse , jewalt@lgsinnovations.com, rafal@milecki.pl, Arend van Spriel , "Rafael J. Wysocki" , atull@kernel.org, Moritz Fischer , pmladek@suse.com, Johannes Berg , emmanuel.grumbach@intel.com, Luca Coelho , luto@kernel.org, Linus Torvalds , Kees Cook , David Howells , pjones@redhat.com, Hans de Goede , alan@linux.intel.com, "Theodore Ts'o" , paul.gortmaker@windriver.com, mtosatti@redhat.com, mawilcox@microsoft.com, Stephen Boyd , Vikram Mulukutla , lkml , oss-drivers@netronome.com Subject: Re: [PATCH] firmware: wake all waiters Message-ID: <20170627195239.GL18666@tuxbook> References: <20170623233702.20564-1-jakub.kicinski@netronome.com> <20170626212036.GE21846@wotan.suse.de> <20170626191009.0c11eed0@cakuba.netronome.com> <20170627180341.GT21846@wotan.suse.de> <20170627185915.GK18666@tuxbook> <20170627190853.GX21846@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170627190853.GX21846@wotan.suse.de> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1800 Lines: 41 On Tue 27 Jun 12:08 PDT 2017, Luis R. Rodriguez wrote: > On Tue, Jun 27, 2017 at 11:59:15AM -0700, Bjorn Andersson wrote: > > On Tue 27 Jun 11:03 PDT 2017, Luis R. Rodriguez wrote: > > [..] > > > Let's consider a crazy case where the uevent gets triggered, and userspace goes > > > and signals Elon Musk somehow to transmit the needed firmware from Mars through > > > a serial satellite link to earth, and somehow someday the device is finally > > > ready to upload firmware from userspace. Once Elon's firmware lands home, we > > > know all needed firmware has arrived so anything missing we can acknowledge now > > > as missing, so we upload what we can and kick firmward into final-mode to tell > > > the kernel we know we're really ready and any pending things will have to be > > > given up. > > > > > > This would prove the custom fallback crap was also never needed. > > > > > > > Are you saying that each kernel driver should be written so that it will > > either do direct loading or use firmwared? > > Hell No! You can fork firmwared or use whatever the hell bin-foo you want. > Even if its proprietary and glued with evil rainbow unicorns on it. The dual > mode, best-effort mode and final-mode devices it implemented are key to what > you want to mimic as an example to achieve the goal in question. > I'm sorry but your language is totally inappropriate and the reason why I tend to stay away from firmware-related discussions. > Please give that thought / architecture solution a spin and let me know if > it suffices for your needs. > Which solution do you refer to here? But as I said, in my view, the decision of making the kernel depend on a user space firmware loading mechanism or direct loading should be that of the system designer - not the kernel. Regards, Bjorn