Re: Intel Microcode loader, tg3 driver, and the -rc8-mmotd New World Order firmware...

[David Woodhouse <dwmw2@infradead.org>]

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...

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).

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

-- 
dwmw2