public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Lin, Derek (HPS SW)" <derek.lin2@hpe.com>
To: devel@edk2.groups.io
Subject: Capsule PCI device firmware update, could capsule embedded driver override PCI option ROM driver?
Date: Thu, 08 Aug 2019 01:27:04 -0700	[thread overview]
Message-ID: <10206.1565252824023648157@groups.io> (raw)

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1243 bytes --]

             reply	other threads:[~2019-08-08  8:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-08  8:27 Lin, Derek (HPS SW) [this message]
2019-08-09 11:13 ` [edk2-devel] Capsule PCI device firmware update, could capsule embedded driver override PCI option ROM driver? Tomas Pilar (tpilar)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10206.1565252824023648157@groups.io \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox