Re: microcode driver newly spews warnings

[Dmitry Adamushko <dmitry.adamushko@gmail.com>]

2009/4/17 H. Peter Anvin <hpa@zytor.com>:
> Jeff Garzik wrote:
>>>
>>> Jeff, did this do the trick for you?
>>
>> Yes -- but I worry about keeping sysfs files around too long?
>>
>>    Jeff
>
> OK, what isn't clear to me is what the proper return value is in this case.
>  In particular, how with the caller react to mc_sysdev_add() returning a
> nonzero value, but still have the sysdev devices created and retained?
>
> What I would expect happen would be that sysdev_register_driver() would
> return an error and we would unregister the notifier, which really isn't the
> right thing -- if the intent is to keep the sysdev devices around for a
> possible later update then we should presumably return zero there, i.e.
> ignore the return value from microcode_init_cpu(); completely?

sysdev_driver_register() doesn't seem to check return values of ->add
callbacks (mc_sysdev_add() in our case). That's why I also wondered
why in this case the microcode module gets unloaded shortly after
having been loaded (maybe the startup script actually checks the
availability of these sysdev files?)

My first impression is that we shouldn't treat the case when a proper
ucode is not found in the firmware as an error. Say, what is a user
upgrades manually via /dev/microcode later on?

>
>        -hpa
>

-- 
Best regards,
Dmitry Adamushko