Hi,
> To make things worse I see that if we return success there EDK2 will
> actually go ahead and start assigning trash addresses to the device
> and enable IO space decoding in case of the PCI root port which means
> that device will try to decode invalid IO ranges.
> Logs:
> PciBus: Resource Map for Root Bridge PciRoot(0x0)
> Type = Io16; Base = 0xFFFFFFFFFFFFFFFF; Length = 0x1000; Alignment = 0xFFF
That is wrong indeed.
I think *this* should work ...
+ } else if ((Index == TypeIo) &&
+ (RootBridge->Io.Base == MAX_UINT64) &&
+ (RootBridge->ResAllocNode[Index].Length == 0)) {
+ /* I/O is optional on PCIe */
+ DEBUG ((DEBUG_INFO, "Success (PCIe NoIO)\n"));
... i.e. return success only in case there are no allocation requests
for IO ranges.
> > Also note that for pcie root bridges which do support io address space
> > this patch changes nothing.
>
> It seems to me like it does.
It doesn't. When io address space is present the "RootBridge->Io.Base
== MAX_UINT64" check will never be true.
But the "no io address space" case was wrong indeed.
> I think to really handle it we would have to have a more involved
> change.
If we want support PCIe devices with I/O bars behind a PCIe host bridge
without I/O window, then yes. My main focus is supporting PCIe devices
without I/O bars though. This doesn't work currently because the code
considers a pcie host bridge without I/O window a hard failure even in
case there are no I/O allocation requests. For fixing that the five
lines above should be enough I think.
thanks & take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90108): https://edk2.groups.io/g/devel/message/90108
Mute This Topic: https://groups.io/mt/90623478/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
