public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>,
	Valdis.Kletnieks@vt.edu,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, jonathan@jonmasters.org,
	Shaohua Li <shaohua.li@intel.com>,
	greg@kroah.com, arjan@infradead.org
Subject: Re: Intel Microcode loader, tg3 driver, and the -rc8-mmotd New World Order firmware...
Date: Thu, 03 Jul 2008 13:32:07 +0200	[thread overview]
Message-ID: <1215084727.9721.82.camel@linux.site> (raw)
In-Reply-To: <1215081776.10393.531.camel@pmac.infradead.org>

On Thu, 2008-07-03 at 11:42 +0100, David Woodhouse wrote:
> On Thu, 2008-07-03 at 12:22 +0200, Kay Sievers wrote:
> > So, maybe a:
> >   # rewrite firmware file name to all-in-one Intel CPU microcode data file
> >   SUBSYSTEM=="firmware", ENV{FIRMWARE}=="intel-ucode/*", ENV{FIRMWARE}="intel-ucode/microcode.dat"
> > would be enough?
> 
> Nah, it needs the binary form. The actual 'microcode.dat' just looks
> like this...

Ah, I see.

> 0x00000001,     0x00000013,     0x02062001,     0x00000683,
> 0x2f0da1b0,     0x00000001,     0x00000001,     0x00000000,
> 0x00000000,     0x00000000,     0x00000000,     0x00000000,
> 0xbf5ad468,     0xc79f5237,     0xbd53889e,     0x896bfd13,
> 0x7adc0c8f,     0x44e9e0bc,     0x1a331fc9,     0x00b0f479,
> 
> That's all microcode_ctl actually does; read in the text file and output
> the (complete) binary. Hence:
>       /sbin/microcode_ctl -f "$DIR/microcode.dat" -d /sys$DEVPATH/data
> 
> At a later date, we could make userspace output only the part for the
> desired CPU, and rip out the kernel-side code which searches for it
> within the big blob. That was presumably the intention in the commit
> which changed things. But then again, the kernel-side code still needs
> to do a certain amount of sanity checking on what it receives -- so I'm
> not sure we gain a huge amount by trying to remove that functionality
> from the kernel (not that I've looked hard at the line count).

I think, the in-kernel selection logic is nice, people can still
provide a custom .bin file which contains only the needed code for the
actual CPU, and it will not really do any "search", right?

> If we're _not_ going to make userspace provide only what's required, and
> we keep the selection code in the kernel, then I don't see the point in
> having separate firmware filenames for different cpus. We could just
> change the driver to call request_firmware("intel-microcode.bin") and do
> this one-off conversion:
> 	touch /lib/firmware/intel-microcode.bin
> 	microcode_ctl -d /lib/firmware/intel-microcode.bin

Sounds fine, yeah. With the in-kernel search, we should make the file
just a name without the CPU id. This would also make it easier to find
and include the fw into the kernel, right?

We could always export the CPU id somewhere else, so "advanced" tools
could look it up in sysfs and upload in a "custom" way. I don't think
anybody will really need that. :)

Thanks,
Kay


  reply	other threads:[~2008-07-03 12:04 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-03  1:32 Intel Microcode loader, tg3 driver, and the -rc8-mmotd New World Order firmware Valdis.Kletnieks
2008-07-03  1:43 ` Andrew Morton
2008-07-03  6:17 ` Tigran Aivazian
2008-07-03  6:35   ` Valdis.Kletnieks
2008-07-03  6:44     ` Tigran Aivazian
2008-07-03  9:23       ` David Woodhouse
2008-07-03 10:17         ` Valdis.Kletnieks
2008-07-03 10:30           ` David Woodhouse
2008-07-03 11:34             ` Valdis.Kletnieks
2008-07-03 12:21               ` David Woodhouse
2008-07-03 12:41                 ` Kay Sievers
2008-07-03 12:45                   ` David Woodhouse
2008-07-03 13:03                     ` Kay Sievers
2008-07-03 13:26                       ` David Woodhouse
2008-07-03 13:54                       ` Valdis.Kletnieks
2008-07-03 15:23                         ` David Woodhouse
2008-07-03 13:48                 ` Valdis.Kletnieks
2008-07-03 10:22         ` Kay Sievers
2008-07-03 10:42           ` David Woodhouse
2008-07-03 11:32             ` Kay Sievers [this message]
2008-07-03  9:24       ` Giacomo A. Catenazzi
2008-07-03 13:56         ` Arjan van de Ven
2008-07-03 15:54           ` David Woodhouse
2008-07-03 16:22             ` Giacomo A. Catenazzi

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=1215084727.9721.82.camel@linux.site \
    --to=kay.sievers@vrfy.org \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=dwmw2@infradead.org \
    --cc=greg@kroah.com \
    --cc=jonathan@jonmasters.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaohua.li@intel.com \
    --cc=tigran@aivazian.fsnet.co.uk \
    /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