From: Jani Nikula <jani.nikula@linux.intel.com>
To: Seth Forshee <seth.forshee@canonical.com>,
intel-gfx@lists.freedesktop.org,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: kbl_guc and bxt_guc firmware missing from linux-firmware
Date: Wed, 15 Feb 2017 12:28:42 +0200 [thread overview]
Message-ID: <8760kbrbmt.fsf@intel.com> (raw)
In-Reply-To: <20170214133948.GB41863@ubuntu-hedt>
On Tue, 14 Feb 2017, Seth Forshee <seth.forshee@canonical.com> wrote:
> Hi,
>
> I've noted that kbl_guc_ver9_14.bin and bxt_guc_ver8_7.bin are not in
> linux-firmware despite being available here:
>
> https://01.org/linuxgraphics/downloads/firmware
>
> Is there some reason they haven't been pusehd out to linux-firmware,
> e.g. are they not yet stable or something like that? Any reason we
> shouldn't ship those files in Ubuntu's linux-firmware?
None that I know of. Rodrigo, please send the pull request to
linux-firmware if you haven't already.
> Frankly, the practice of adding MODULE_FIRMWARE statements to i915 for
> files which aren't in linux-firmware has become a significant annoyance
> to me as Ubuntu's linux-firmware package maintainer. I'm getting a
> steady stream of bug reports from users about the "Possible missing
> firmware ..." messages from mkinitramfs, to the point that I've started
> removing the MODULE_FIRMWARE statements for those files from our
> kernels.
Admittedly we've probably done that even before the firmware has hit
01.org, and we should fix this. We don't have a long history of dealing
with firmware blobs, and your feedback is appreciated.
I think my main question is, what are the downsides of requesting a
firmware even if it hasn't been declared using a MODULE_FIRMWARE
statement? I don't see anything preventing that. Is MODULE_FIRMWARE
purely informational, to help ensure the packaging gets it right?
We do need to have the firmware loading code in place long before we
actually publish the firmware, to test the stuff. Could we get away with
adding the MODULE_FIRMWARE statements only after the blobs have hit
linux-firmware?
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-02-15 10:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-14 13:39 kbl_guc and bxt_guc firmware missing from linux-firmware Seth Forshee
2017-02-15 10:28 ` Jani Nikula [this message]
2017-02-15 13:01 ` Seth Forshee
2017-02-15 22:56 ` Vivi, Rodrigo
2017-03-01 13:23 ` Jani Nikula
2017-03-01 14:20 ` Seth Forshee
2017-03-15 10:54 ` Jani Nikula
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=8760kbrbmt.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigo.vivi@intel.com \
--cc=seth.forshee@canonical.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