On 6/1/20 11:37 AM, Andrei Warkentin wrote:
Hi Ard,
The xHCI controller is initialized with its microcode by the VPU
firmware, if
I understood correctly, synchronously. When RPI_MBOX_NOTIFY_XHCI_RESET
finishes, the XHCI controller is ready to go.
I suppose there are no other agents that may consume the config space
during this time, right?
So this is not any more unsafe than any of the other mailbox calls. To
be honest, I think RpiFirmwareDxe should be cleaned up to replace the
useless spinlocks (there's no multiprocessing component) with a TPL
manip (I checked SynchonizationLib and it doesn't touch the TPL)
The spinlock protects from re-entrancy: if an event callback routine
(such as the one you are adding for PCI I/O protocol registration)
attempts to do a firmware call while one is already in progress, it will
fail.
But perhaps it is indeed better to run at TPL_NOTIFY level - that way,
the calls will be ordered one after the other instead of one being shot
down.
Applying your other feedback now...
A
------------------------------------------------------------------------
*From:* devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Ard
Biesheuvel via groups.io <ard.biesheuvel=arm....@groups.io>
+
+ Status = MailboxTransaction (Cmd->BufferHead.BufferSize, RPI_MBOX_VC_CHANNEL,
&Result);
+
So this pokes the XHCI controller via its config space? Is it safe to do
that without raising the TPL? What happens if another config space
access occurs concurrently?
A
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#60495): https://edk2.groups.io/g/devel/message/60495
Mute This Topic: https://groups.io/mt/74596471/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
