All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: Prarit Bhargava <prarit@redhat.com>,
	Ming Lei <ming.lei@canonical.com>, Borislav Petkov <bp@suse.de>,
	x86@kernel.org, amd64-microcode@amd64.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/4] Add request_firmware_direct() for microcode loader
Date: Mon, 2 Dec 2013 06:32:45 -0800	[thread overview]
Message-ID: <20131202143245.GA32266@kroah.com> (raw)
In-Reply-To: <s5h38mbabhe.wl%tiwai@suse.de>

On Mon, Dec 02, 2013 at 09:44:13AM +0100, Takashi Iwai wrote:
> At Sat, 16 Nov 2013 06:24:55 +0900,
> Greg Kroah-Hartman wrote:
> > 
> > On Fri, Nov 15, 2013 at 04:34:09PM +0100, Takashi Iwai wrote:
> > > At Tue, 12 Nov 2013 13:02:12 +0100,
> > > Takashi Iwai wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > this is a revised patch series to introduce request_firmware_direct()
> > > > helper for avoiding the lengthy udev issue on microcode loader.
> > > > The original problem was stated in Prarit's post:
> > > >    https://lkml.org/lkml/2013/10/28/221
> > > > 
> > > > In short, microcode loader probes non-existing firmware files (which
> > > > are cases with every new chip), and each probe takes 60 seconds,
> > > > resulting in too long time until completed.
> > > > 
> > > > This solution is simply avoiding the udev fallback in
> > > > request_firmware() explicitly for drivers like microcode.
> > > > 
> > > > Of course, this doesn't mean to throw away further optimizations like
> > > > Prarit's patch.  It can be implemented in parallel with this.
> > > > 
> > > > 
> > > >  [PATCH v3 1/4] firmware: Introduce request_firmware_direct()
> > > >  [PATCH v3 2/4] microcode: Use request_firmware_direct()
> > > >  [PATCH v3 3/4] firmware: Use bit flags instead of boolean combos
> > > >  [PATCH v3 4/4] firmware: Suppress fallback warnings when CONFIG_FW_LOADER_USER_HELPER=n
> > > > 
> > > > v1->v2: Rebased on linux-next, add a fix for a bogus warning message
> > > > v2->v3: Convert to bit flags, fix warning message differently
> > > > 
> > > > 
> > > > Greg, could you take these patches through your driver tree, as
> > > > most of fixes are about the firmware loader itself.
> > > 
> > > Greg, any chance to take a look at these patches?
> > 
> > I'm traveling at the moment, in Korea this week.  I'll take a look at
> > them after 3.13-rc1 is out, as I can't do anything with patches until
> > then.  Don't worry, they aren't lost.
> 
> They seem lost in Korea in the end :)

No, not lost:
	$ mdfrm -c ~/mail/todo/
	2485 messages in /home/gregkh/mail/todo/

Just burried :(

> Could you catch up if still OK?

I'll get to them soon...

> One of the patches seems slightly conflicting with the latest Linus
> tree.  I can send a rebased one if needed, or you can take it from
>   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git test/fw-direct

Yes please, an update would be good to have, can you just send this in
email form?

thanks,

greg k-h

  reply	other threads:[~2013-12-02 14:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-12 12:02 [PATCH v3 0/4] Add request_firmware_direct() for microcode loader Takashi Iwai
2013-11-12 12:02 ` [PATCH v3 1/4] firmware: Introduce request_firmware_direct() Takashi Iwai
2013-11-12 12:02 ` [PATCH v3 2/4] microcode: Use request_firmware_direct() Takashi Iwai
2013-11-12 12:02 ` [PATCH v3 3/4] firmware: Use bit flags instead of boolean combos Takashi Iwai
2013-11-12 12:02 ` [PATCH v3 4/4] firmware: Suppress fallback warnings when CONFIG_FW_LOADER_USER_HELPER=n Takashi Iwai
2013-11-15 15:34 ` [PATCH v3 0/4] Add request_firmware_direct() for microcode loader Takashi Iwai
2013-11-15 21:24   ` Greg Kroah-Hartman
2013-11-16  9:17     ` Takashi Iwai
2013-12-02  8:44     ` Takashi Iwai
2013-12-02 14:32       ` Greg Kroah-Hartman [this message]
2013-12-02 14:35         ` Takashi Iwai

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=20131202143245.GA32266@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=amd64-microcode@amd64.org \
    --cc=bp@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@canonical.com \
    --cc=prarit@redhat.com \
    --cc=tiwai@suse.de \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.