linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Ming Lei <ming.lei@redhat.com>,
	yi1.li@linux.intel.com, takahiro.akashi@linaro.org,
	nbroeking@me.com, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	mfuzzey@parkeon.com, ebiederm@xmission.com,
	dmitry.torokhov@gmail.com, wagi@monom.org, dwmw2@infradead.org,
	jewalt@lgsinnovations.com, rafal@milecki.pl,
	arend.vanspriel@broadcom.com, rjw@rjwysocki.net,
	atull@kernel.org, moritz.fischer@ettus.com, pmladek@suse.com,
	johannes.berg@intel.com, emmanuel.grumbach@intel.com,
	luciano.coelho@intel.com, luto@kernel.org,
	torvalds@linux-foundation.org, keescook@chromium.org,
	dhowells@redhat.com, pjones@redhat.com, hdegoede@redhat.com,
	alan@linux.intel.com, tytso@mit.edu,
	paul.gortmaker@windriver.com, mtosatti@redhat.com,
	mawilcox@microsoft.com, stephen.boyd@linaro.org,
	markivx@codeaurora.org, linux-kernel@vger.kernel.org,
	oss-drivers@netronome.com
Subject: Re: [PATCH] firmware: wake all waiters
Date: Mon, 26 Jun 2017 19:10:09 -0700	[thread overview]
Message-ID: <20170626191009.0c11eed0@cakuba.netronome.com> (raw)
In-Reply-To: <20170626212036.GE21846@wotan.suse.de>

On Mon, 26 Jun 2017 23:20:36 +0200, Luis R. Rodriguez wrote:
> > In that case we will make them all use the same struct firmware_buf.
> > When wake up happens make sure it's propagated to all of them.
> > 
> > Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>  
> 
> There's a slew of bugs lurking here though!
> 
> As noted the reported Intel driver issues still need other fixes, one was the
> fw_state_done() on the direct filesystem lookup mechanism [1], and that may be
> a regression since direct filesystem loading was added, and even secondary
> requests would seem to just wait forever (MAX_SCHEDULE_TIMEOUT); the combination
> of both fixes should fix your reported issue.
> 
> Do you intend on submitting those changes as well ? There's still *other* bugs
> with this feature though... Knowing if you will follow up with further fixes
> will be appreciated.

No, I don't have any more fixes in my tree right now :)  What I'm
looking towards implementing is actually a ability for NICs to load
default FW but then enable users to load different FW on their request. 

The problem is that advanced NICs are quite programmable [1] and
depending on use case one may want to load different firmware files.
It's slightly close to the FPGA use case, only with FPGA people don't
expect much plug and play, and with NICs the default mode after boot
must be "look as much as a standard NIC as possible".  Then loading
"advanced"/hand crafted firmware can turn more interesting features on.

The FW loading we have now in drivers/net/ethernet/netronome/nfp is
requesting default FW and returning -EPROBE_DEFER if not found.  Now I
need to find a way to allow users to "push" whatever advanced FW they
have into the NIC after/during boot.

Current firmware subsystem doesn't seem to cater to this use case to
well.  I have to look at the FPGA-related code.  The three main
problems to solve are:
 - how to stay bound and retry the direct default FW load until rootfs
   is mounted (equivalent to when -EPROBE_DEFER would give up);
 - how to expose permanent FW loading sysfs interface which won't
   disappear after the first -1/1 is written to .../loading;
 - how to make sure different cards, which request the same file name
   can be served different default firmwares...


Thanks for the improved commit message!

[1] HW links:
https://www.hotchips.org/wp-content/uploads/hc_archives/hc25/HC25.60-Networking-epub/HC25.27.620-22nm-Flow-Proc-Stark-Netronome.pdf
https://www.netronome.com/media/pdfs/NFP_Programming_Model_h6vxM7Y.pdf
http://open-nfp.org/resources/

  parent reply	other threads:[~2017-06-27  2:10 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-23 23:37 [PATCH] firmware: wake all waiters Jakub Kicinski
2017-06-26 21:20 ` Luis R. Rodriguez
2017-06-26 21:23   ` [PATCH v2] firmware: fix batched requests - " Luis R. Rodriguez
2017-06-29 15:16     ` Greg KH
2017-06-29 15:17       ` Greg KH
2017-06-29 17:36         ` Luis R. Rodriguez
2017-06-26 23:41   ` [PATCH] firmware: " Luis R. Rodriguez
2017-06-27  2:10   ` Jakub Kicinski [this message]
2017-06-27 16:39     ` Luis R. Rodriguez
2017-06-27 21:25       ` Jakub Kicinski
2017-06-27 22:24         ` Luis R. Rodriguez
2017-06-27 22:39           ` Jakub Kicinski
2017-06-27 23:50             ` Luis R. Rodriguez
2017-06-28  7:06           ` [systemd-devel] " Lennart Poettering
2017-06-28 16:06             ` Luis R. Rodriguez
2017-06-28 16:21               ` Lennart Poettering
2017-06-28 17:57                 ` Luis R. Rodriguez
2017-06-29 19:56               ` Daniel Wagner
2017-06-27 17:48     ` Bjorn Andersson
2017-06-27 18:03       ` Luis R. Rodriguez
2017-06-27 18:59         ` Bjorn Andersson
2017-06-27 19:08           ` Luis R. Rodriguez
2017-06-27 19:52             ` Bjorn Andersson
2017-06-27 20:24               ` Luis R. Rodriguez
2017-06-26 21:44 ` Linus Torvalds
2017-06-26 23:30   ` Luis R. Rodriguez
2017-06-26 23:43     ` Linus Torvalds
2017-06-27  0:15       ` Luis R. Rodriguez
2017-06-28 13:45         ` Davidlohr Bueso
2017-06-28 15:58           ` Luis R. Rodriguez
2017-06-28 19:03             ` Davidlohr Bueso
2017-06-29 19:08         ` Davidlohr Bueso
2017-06-29 19:48           ` Luis R. Rodriguez
2017-06-30 16:32             ` Davidlohr Bueso
2017-07-05 16:18     ` Peter Zijlstra
2017-07-05 16:33       ` Linus Torvalds
2017-07-12 18:45         ` Luis R. Rodriguez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170626191009.0c11eed0@cakuba.netronome.com \
    --to=jakub.kicinski@netronome.com \
    --cc=alan@linux.intel.com \
    --cc=arend.vanspriel@broadcom.com \
    --cc=atull@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=ebiederm@xmission.com \
    --cc=emmanuel.grumbach@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=jewalt@lgsinnovations.com \
    --cc=johannes.berg@intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luciano.coelho@intel.com \
    --cc=luto@kernel.org \
    --cc=markivx@codeaurora.org \
    --cc=mawilcox@microsoft.com \
    --cc=mcgrof@kernel.org \
    --cc=mfuzzey@parkeon.com \
    --cc=ming.lei@redhat.com \
    --cc=moritz.fischer@ettus.com \
    --cc=mtosatti@redhat.com \
    --cc=nbroeking@me.com \
    --cc=oss-drivers@netronome.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=pjones@redhat.com \
    --cc=pmladek@suse.com \
    --cc=rafal@milecki.pl \
    --cc=rjw@rjwysocki.net \
    --cc=stephen.boyd@linaro.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=wagi@monom.org \
    --cc=yi1.li@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).