public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Giacomo A. Catenazzi" <cate@cateee.net>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Sitsofe Wheeler <sitsofe@yahoo.com>,
	Dragoslav Zaric <dragoslav.zaric.kd@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Linux* Processor Microcode Data File
Date: Thu, 12 Mar 2009 11:03:11 +0100	[thread overview]
Message-ID: <49B8DDDF.8080708@cateee.net> (raw)
In-Reply-To: <20090309095330.30278385@infradead.org>

Arjan van de Ven wrote:
> On Mon, 9 Mar 2009 15:34:50 +0000
> Sitsofe Wheeler <sitsofe@yahoo.com> wrote:
> 
>> On Mon, Mar 09, 2009 at 08:11:09AM -0700, Arjan van de Ven wrote:
>>> On Mon, 9 Mar 2009 14:16:55 +0000
>>> Sitsofe Wheeler <sitsofe@yahoo.com> wrote:
>>>
>>>> The kernel doesn't load microcode automatically 
>>> it does if you have the right format; the kernel uses
>>> request_firmware() for this.
>>> The microcode on the intel website is not ready for this yet, but
>>> we're working hard to have future drops to be in the new format.
>> Wow so I was redundant AND wrong in the same email!
>>
>> What motivated the switch to the generic request_firmware interface?
>> Is it just less messy/faster than previous methods? 
> 
> there are various cases where microcode is needed (for example, when
> you hotplug a new cpu); request_firmware() is just the right way to do
> such things, and an initscript is just the wrong way

I don't agree ;-)
I agree that request_firmware method is better than init.d scripts, but
not that it is the right things. microcodes should be loaded at very
beginning of boot process, so by BIOS, by GRUB or on hotpug event by
request_firmware.
BTW: why do we have microcode loading modular?

Offtopic: IMHO if we could move the load of firmware before booting
linux, it would be nicer and cleaner (by open source point of view).

ciao
	cate


  reply	other threads:[~2009-03-12 10:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-09  9:43 Linux* Processor Microcode Data File Dragoslav Zaric
2009-03-09 10:00 ` Jike Song
2009-03-09 10:30   ` Andreas Herrmann
2009-03-09 14:16 ` Sitsofe Wheeler
2009-03-09 15:11   ` Arjan van de Ven
2009-03-09 15:34     ` Sitsofe Wheeler
2009-03-09 15:58       ` Gene Heskett
2009-03-09 16:24         ` Sitsofe Wheeler
2009-03-09 17:03           ` Gene Heskett
2009-03-09 17:57           ` Andreas Herrmann
2009-03-09 16:53       ` Arjan van de Ven
2009-03-12 10:03         ` Giacomo A. Catenazzi [this message]
2009-03-12 14:07           ` Arjan van de Ven
2009-03-13  8:37             ` Giacomo A. Catenazzi
     [not found]             ` <2d05c4580903130142o2e5ebbcfw1e35eb52ea48e4b1@mail.gmail.com>
2009-03-13  8:44               ` Dragoslav Zaric
2009-03-13 14:55                 ` Gene Heskett
2009-03-12 14:53           ` Dragoslav Zaric
2009-03-09 14:27 ` Arjan van de Ven

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=49B8DDDF.8080708@cateee.net \
    --to=cate@cateee.net \
    --cc=arjan@infradead.org \
    --cc=dragoslav.zaric.kd@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sitsofe@yahoo.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