Re: [PATCH 2/2] x86, microcode: Make reload interface per system

[Henrique de Moraes Holschuh]

On Wed, 20 Jun 2012, Peter Zijlstra wrote:
> On Wed, 2012-06-20 at 12:19 +0200, Borislav Petkov wrote:
> > On Wed, Jun 20, 2012 at 12:08:51PM +0200, Peter Zijlstra wrote:
> > > On Wed, 2012-06-20 at 11:56 +0200, Borislav Petkov wrote:
> > > >         sprintf(name, "intel-ucode/%02x-%02x-%02x",
> > > >                 c->x86, c->x86_model, c->x86_mask);
> > > 
> > > but but but, the ucode image actually contains stuff for multiple
> > > things.. so I have to like rename it to match the actual cpu in the
> > > machine?
> > > 
> > > That seems rather daft..
> > > 
> > > awk 'BEGIN { FS=":" } /family/ {fam=$2} /model[^ ]/ {mod=$2} /stepping/
> > > {step=$2} END { printf "intel-ucode/%02x-%02x-%02x\n", fam, mod,
> > > step }' /proc/cpuinfo
> > > 
> > > Will get me the right filename, but surely that's not user-friendly at
> > > all...
> > 
> > I know, right. Whose idea was it to do it like that I don't know.
> > AFAICT, Intel delivers ucode as a single blob too, so why split it? The
> > driver picks out the right blob anyway.
> 
> Right, so since we're mucking about with the whole interface anyway,
> can't we fix this too?

Please!

Just make it attempt to load a statically named firmware file first, and
fall back to the older variable naming.

If the reason for the weird naming is a size concern, "iucode_tool
--scan-system -w /lib/firmware/intel-ucode/x86.bin" (or whatever you name
it) would create a file with just the microcode required by the (online)
processors in the running system.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/