On Sun, Apr 26, 2015 at 05:03:14PM +0200, Alexander Hirsch wrote: > Microcode can be baked into the kernel image via CONFIG_EXTRA_FIRMWARE > and the early loader supports that, but still depended on > BLK_DEV_INITRD. > This dependency is removed.
Yeah, it is removed but it adds a bunch of ugly ifdeffery which makes the code even more unreadable than it is :-\ > Signed-off-by: Alexander Hirsch <[email protected]> > --- > > This patch depends on the "Parse built-in microcode early" patch by > Borislav Petkov (https://lkml.org/lkml/2015/4/1/331). In the future, please CC me on microcode loader patches. > I only tested this on two Intel machines (an i3 M330 and an i5-4690). > There is no change in amd_early.c because it compiles fine - only > intel_early.c complained without BLK_DEV_INITRD. Right, so I see what you're trying to achieve and I'd guess your reasoning is that BLK_DEV_INITRD is not really needed if you build your microcode into the kernel. And that's ok but I'm not persuaded yet: * why do you even bother - BLK_DEV_INITRD gets enabled on all distro kernels and almost everything running Linux so why bother? Or do you have a special use case which doesn't want BLK_DEV_INITRD. I'd be interested to hear about it. * the early loader was done with initrd in mind and it was/still is its main source for microcode blobs early in the boot. So if we want to make it not-mandatory, then the driver needs to be reorganized so that builtin blobs and initrd blobs loading paths are cleanly untangled. The ifdeffery thing might work now but is certainly not future-proof so it would need to be designed in a cleaner way. Perhaps something like a microcode cache of patches the AMD loader has, all decoupled from the loading paths or so... I don't have a good idea right now. I'll have to think about it. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
