Hi,

We also implement capsules to update optionROMs that use an embedded 
driver in the capsule. The main reason for us is space - crypto library 
is too large to fit into our flash so we don't provide fully functional 
FMP in the optionROM driver, only a stub FMP that is enough to populate 
the ESRT.

The spec requires that the embedded driver is loaded by the platform. I 
would also _expect_ that the platform will try to bind the driver 
against all devices in the platform using the DriverBinding protocol - 
this is quite a necessary step for using a driver!

I wouldn't expect the platform to unbind the old driver from the device 
for me, in fact it should not assume it knows the right thing to do 
here. I implemented this unbinding internally: when my embedded driver 
loads, it will unbind all (my) existing drivers during the EntryPoint 
execution. That leaves the controllers free to be bound against using 
the embedded driver.

In fact, if your IHV is writing drivers that are supposed to work in 
general on other platforms as well, they better not rely on this kind of 
special behaviour!

Caveats:

This does potentially cause a problem if existing drivers are very old 
and buggy and crash the platform during unbinding. It will also leave 
the controller without a proper driver following the update. This is 
okay since we expect the platform to reboot following an FMP update.

Cheers,

Tom

P.S. If you put me in contact with your IHV I can explain how I 
implemented the unbinding on our end.


On 08/08/2019 09:27, Lin, Derek (HPS SW) wrote:
> Hi,
>
> I have searched EDK2 devel discussion and Mantis but I couldn't find 
> answer.
>
>
> Recently we found some PCI card vendor release capsule to update 
> device firmware.
>
> Background:
> The PCI card has option ROM which provide FMP service.
> The capsule has a firmware payload and device driver which also 
> provide FMP.
>
> Problem:
> The vendor put option ROM device driver into capsule, the only 
> differences is it is newer version.
> The FMP in old PCI option ROM is not functional.
> Thus they put a new device driver in capsule, and expect UEFI to 
> disconnect the old option ROM driver, and connect the new one from 
> capsule.
>
> This is different to current EDK2 implementation. UEFI spec 2.8 CH 
> 23.3.3 define process to handle capsule and embedded driver, it will 
> call embedded driver's entry point, but won't connect anything.
>
> Our PCI card vendor is asking to disconnect old option ROM driver, and 
> connect new driver from capsule.
> It makes sense for device vendor to simply provide a device driver in 
> capsule.
>
>
> Any advice? Do you think it make sense to disconnect PCI option ROM 
> driver and reconnect capsule driver?
>
> Thanks,
> Derek
>