From: Seth Forshee <seth.forshee@canonical.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: 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 07:01:40 -0600 [thread overview]
Message-ID: <20170215130140.GC41863@ubuntu-hedt> (raw)
In-Reply-To: <8760kbrbmt.fsf@intel.com>
On Wed, Feb 15, 2017 at 12:28:42PM +0200, Jani Nikula wrote:
> 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?
The only downside I know of is this. mkinitramfs uses the modinfo
firmware field to copy firmware into the initrd along with the kernel
module, so when i915.ko is copied to the initrd that firmware would not
be copied along with it. There may be other tools using that modinfo
field that I'm not aware of though.
Maybe it would be good to have something like MODULE_OPTIONAL_FIRMWARE
to identify firmware that isn't required but will be used by the driver
if available. Then mkinitramfs can try to copy those files along with
the module but know that there's no need to produce a warning if it's
not present.
Thanks,
Seth
_______________________________________________
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 13:01 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
2017-02-15 13:01 ` Seth Forshee [this message]
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=20170215130140.GC41863@ubuntu-hedt \
--to=seth.forshee@canonical.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=rodrigo.vivi@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