From: "Li, Yi" <yi1.li@linux.intel.com>
To: Alan Tull <delicious.quinoa@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: ming.lei@canonical.com, mcgrof@kernel.org,
atull <atull@opensource.altera.com>,
Moritz Fischer <moritz.fischer@ettus.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-fpga@vger.kernel.org
Subject: Re: [RFC 1/2] firmware class: Add stream_firmware API.
Date: Wed, 22 Mar 2017 17:05:00 -0500 [thread overview]
Message-ID: <130097e7-fe9b-dce5-8bda-f22f352f7a44@linux.intel.com> (raw)
In-Reply-To: <CANk1AXSKg1OvHHhjOOb8oWu=jWi-KgzWHhXtaiqRYjFkVvxCVg@mail.gmail.com>
Alan
On 3/20/2017 1:34 PM, Alan Tull wrote:
> On Mon, Mar 20, 2017 at 1:00 PM, Alan Tull <delicious.quinoa@gmail.com> wrote:
>
>>> +int
>>> +stream_firmware(const struct firmware **firmware_p, const char *name,
>>> + struct device *device, size_t offset, size_t length)
>>> +{
>>> + size_t ret;
>>> +
>>> + /* Need to pin this module until return */
>>> + __module_get(THIS_MODULE);
>>> + ret = _stream_firmware(firmware_p, name, device, NULL, 0,
>>> + FW_OPT_UEVENT | FW_OPT_NO_WARN, offset, length);
> IIUC, here you are setting size == 0 and buf == NULL to prevent
> _request_firmware_prepare from attempting to load from built in
> firmware.
>
> So three of the parameters buf, size, and opt_flags are fixed and
> don't need to be passed to _stream_firmware().
Sure.
> Alternatively, I wonder how hard it would be to code this so that the
> streaming interface will fall back and successfully get the built in
> or cached firmware if it exists and stream it out in PAGE_SIZE chunks.
That's an interesting idea, I will try it out and submit patch for
review later. On another hand, if the kernel already cache the whole
firmware image, why should we use streaming instead of regular
request_firmware?
>
> Alan Tull
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-03-22 22:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-10 0:18 [RFC 0/2] Add streaming API for firmware and FPGA manager yi1.li
2017-03-10 0:18 ` [RFC 1/2] firmware class: Add stream_firmware API yi1.li
2017-03-10 17:44 ` matthew.gerlach
2017-03-10 19:25 ` Li, Yi
2017-03-13 21:09 ` matthew.gerlach
2017-03-14 16:10 ` Li, Yi
2017-03-14 16:55 ` matthew.gerlach
2017-03-20 18:00 ` Alan Tull
2017-03-20 18:34 ` Alan Tull
2017-03-22 22:05 ` Li, Yi [this message]
2017-03-23 0:34 ` Alan Tull
2017-03-27 19:36 ` Luis R. Rodriguez
2017-03-27 21:20 ` Li, Yi
2017-03-10 0:18 ` [RFC 2/2] fpga manager: Add fpga_mgr_firmware_stream API yi1.li
2017-03-13 18:00 ` Alan Tull
2017-03-13 19:04 ` Li, Yi
2017-03-10 17:11 ` [RFC 0/2] Add streaming API for firmware and FPGA manager matthew.gerlach
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=130097e7-fe9b-dce5-8bda-f22f352f7a44@linux.intel.com \
--to=yi1.li@linux.intel.com \
--cc=atull@opensource.altera.com \
--cc=delicious.quinoa@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=ming.lei@canonical.com \
--cc=moritz.fischer@ettus.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).