From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Ming Lei <ming.lei@canonical.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] firmware: Be a bit more verbose about direct firmware loading failure
Date: Fri, 13 Sep 2013 10:56:39 -0300 [thread overview]
Message-ID: <20130913135639.GA17010@khazad-dum.debian.net> (raw)
In-Reply-To: <20130912203633.GC8619@hmsreliant.think-freely.org>
On Thu, 12 Sep 2013, Neil Horman wrote:
> On Thu, Sep 12, 2013 at 03:46:30PM -0300, Henrique de Moraes Holschuh wrote:
> > On Thu, 12 Sep 2013, Neil Horman wrote:
> > > Both of these execptions should be rare, and are something the administrator
> > > will want to know about, so as not to confuse the real error with the mystery
> > > -ENOENT you would get if you fell back to the user mode helepr and it wansn't
> > > configured on in the running kernel.
> >
> > Except, of course, for Intel processor microcode updates, which are going to
> > cause ENOENT on a large number of systems.
> >
> > This will generate a large number of questions by users on the distro MLs.
> >
> > However, IMHO this is *not* a reason to refuse this patch series. If
> > anything, at least for Debian I will use it as an opportunity to educate
> > people about the existence of microcode update packages in "non-free".
> >
> I agree. If people are running with downlevel microcode, they shold know about
> it. You can't expect request_firmware to fail silently. If people complain, I
> think the right solution would be to add a test to the microcode_request_fw
> function to check for the existence of the file before requesting it.
Make it a firmware loader API for "optional" firmware (i.e. which doesn't
complain on ENOENT), leaving for the caller the detail of whether a
firmware-not-there failure should be logged or not.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
next prev parent reply other threads:[~2013-09-13 13:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-06 19:36 Neil Horman
2013-09-11 11:54 ` Ming Lei
2013-09-11 14:19 ` Neil Horman
2013-09-12 2:25 ` Ming Lei
2013-09-12 13:16 ` Neil Horman
2013-09-12 14:30 ` Ming Lei
2013-09-12 15:02 ` Neil Horman
2013-09-12 18:46 ` Henrique de Moraes Holschuh
2013-09-12 20:36 ` Neil Horman
2013-09-13 13:56 ` Henrique de Moraes Holschuh [this message]
2013-09-13 15:00 ` Neil Horman
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=20130913135639.GA17010@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=nhorman@tuxdriver.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
all inboxes | Powered by JetHome®