On Wed, Nov 24, 2021 at 14:07:22 +0100, Ard Biesheuvel wrote:
> On Wed, 24 Nov 2021 at 14:05, Leif Lindholm <l...@nuviainc.com> wrote:
> >
> > On Wed, Nov 24, 2021 at 14:03:51 +0100, Ard Biesheuvel wrote:
> > > On Wed, 24 Nov 2021 at 13:07, Leif Lindholm <l...@nuviainc.com> wrote:
> > > >
> > > > Ard - how does this interact with e.g. ArmVirtPsciResetSystemLib,
> > > > which reads its conduit out of the DT passed to it by QEMU?
> > > >
> > >
> > > As long as ArmCallSmc() and ArmCallHvc() continue to exist and behave
> > > as before, I don't think those libraries are affected.
> >
> > Well, I was thinking more that you can now end up with a firmware
> > build where the conduit is sometimes dynamically determined, and
> > sometimes compile-time determined.
>
> There is nothing wrong with that by itself: if you have a DT that
> describes this, it makes sense to carry support for both. If the bare
> metal you are targetting only ever uses SMC, no need for the discovery
> and a PCD is fine.
>
> Question remains whether this PCD could/should be configurable as
> dynamic, so we collapse the static/dynamic options into a single PCD
> based choice.
That would feel cleaner. Although not required for this set.
/
Leif
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84037): https://edk2.groups.io/g/devel/message/84037
Mute This Topic: https://groups.io/mt/87092744/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
