This patch fixes https://bugzilla.tianocore.org/show_bug.cgi?id=367
Cc: Wang Cloud
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao
---
SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Yes. I agree with you.
I will send out patch soon.
From: wang xiaofeng [mailto:winggundu...@163.com]
Sent: Monday, February 6, 2017 9:55 PM
To: edk2-devel@lists.01.org; Yao, Jiewen
Subject: Bug 367 - Version Check for capsule update logic error
Hi Jiewen,
Bug 367 is submitted for Version Che
Hi Jiewen,
Bug 367 is submitted for Version Check for capsule update logic error .
In CapsuleAuthenticateSystemFirmware of
SignedCapsulePkg\Library\EdkiiSystemCapsuleLib\EdkiiSystemCapsuleLib.c, the
following logic seems error
if (ForceVersionMatch) {
if (CurrentImageFmpInfo->Vers
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Laszlo Ersek
---
.../IncompatiblePciDeviceSupport.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git
a/OvmfPkg/IncompatiblePciDeviceSupportDxe/Incompatible
If a platform developer follows the PI spec to write an
IncompatiblePciDeviceSupport driver, due to a spec complaince
bug in PciBus driver, the IncompatiblePciDeviceSupport driver
may not work as expected. The patches fix PciBus to follow Spec
to accept Spec defined values.
v2: Use DISABLE_NEW_DEP
When the VendorId/DeviceId/RevisionId/SubsystemVendorId
/SubsystemDeviceId is MAX_UINTN, IncompatiblePciDeviceSupport
driver doesn't use it to match any IDs.
The patch fixes this bug.
Since PciBus driver always calls IncompatiblePciDeviceSupport
using IDs read from HW, MAX_UINTN is never passed to
When BarIndex equals to 0xFF, default value 0 is used as the BAR
index. Though PCI_BAR_ALL and MAX_UINT8 shares the same value,
using PCI_BAR_ALL is like to match any BAR not BAR 0, it's more
proper to use MAX_UINT8 here.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu
PI spec IncompatiblePciSupport part defines (UINT64)-1 as all BARs
and 0 to use existing alignment. PciBus driver didn't accept these
values. It treated 0xFF as all BARs and 0xULL to use
existing alignment.
The patch changes the code to still accept old values while also
accept valu
DEVICE_ID_NOCARE is defined as 0x but Spec says (UINT64) -1
should be used to match any VendorId/DeviceId/RevisionId/
SubsystemVendorId/SubsystemDeviceId.
PCI_BAR_OLD_ALIGN/PCI_BAR_EVEN_ALIGN/PCI_BAR_SQUAD_ALIGN/
PCI_BAR_DQUAD_ALIGN are defined but Spec doesn't have such
definitions.
PCI_BAR_
The patch replaces the following macros:
DEVICE_ID_NOCARE (0xFF) --> MAX_UINT64
PCI_ACPI_UNUSED (0) --> 0
PCI_BAR_ALL (0xFF) --> MAX_UINT64
PCI_BAR_NOCHANGE (0) --> 0
PCI_BAR_EVEN_ALIGN --> EVEN_ALIGN (local definition)
Since the PciBus driver was updated to accept Spec defined values
in previous
Hi Tom,
Thanks for the clarification. I just want to confirm that it is not a bug in
the common SNP driver.
Best Regards,
Ye Ting
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tomas
Pilar (tpilar)
Sent: Monday, February 06, 2017 10:59 PM
To:
Mike,
OK I will change to MAX_UINT64.
Thanks/Ray
> -Original Message-
> From: Kinney, Michael D
> Sent: Tuesday, February 7, 2017 1:55 AM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org; Kinney, Michael
> D
> Cc: Tian, Feng ; Fan, Jeff
> Subject: RE: [edk2] [PATCH v2 3/6] MdeModulePkg/Incompa
BmExpandMediaDevicePath contains a bug that it uses the
uninitialized Handle.
Since the function is called when the Handle supports BlockIo
or SimpleFileSystem, when there is no SimpleFileSystem installed
on the Handle, BlockIo should be installed on the Handle.
The fix initializes the Handle by l
From: Alexei
"ARM Generic Watchdog base addresses must be declared as UINT64 values"
https://bugzilla.tianocore.org/show_bug.cgi?id=361
PcdGenericWatchdogControlBase & PcdGenericWatchdogRefreshBase
are declared as UINT32 values in ArmPkg.dec, but for platforms
with addresses in the memory range
Ray,
As a follow up, I do see the PI Specification using (UINTN)-1 and (UINT64)-1.
I think the intent is unsigned values with all bits set, which is what the
MAX_UINTx macros provide in the EDK II without depending on type casting a
signed value to an unsigned value.
Mike
> -Original Messa
Jiewen,
Can we simplify the policy setting to 2 bits?
One for FV images and one for non-FV images?
Thanks,
Mike
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, February 6, 2017 6:53 AM
> To: Yao, Jiewen
> Cc: Kinney, Michael D ; edk2-d
Ray,
Can we use MAX_UINT64 instead of (UINT64)-1?
Thanks,
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu
> Ni
> Sent: Sunday, February 5, 2017 10:01 PM
> To: edk2-devel@lists.01.org
> Cc: Tian, Feng ; Fan, Jeff
> Subject: [edk2
Reviewed-by: Phil Dennis-Jordan
Thanks for writing the patch Laszlo! I've finally got around to testing it
out, and I can confirm that unlike previously the FADT it produces is
accepted by Windows 10, when Qemu provides a FADT with revision 3 or 4.
(Windows 10 appears to insist on both DSDT and X
This is the specific implementation of SNP for our driver. We expose
this implementation which is then consumed by MNP so that our NIC can be
used as a NIC. The specific problem is that some functionality that SNP
needs to implement (initializing queues, changing MAC, resetting) are
asynchronous,
On 6 February 2017 at 14:51, Yao, Jiewen wrote:
> Hi Ard
>
> That is a good question.
>
>
>
> We (Intel) discussed this internally.
>
> We do not know if there is any need to make it configurable, so we start
> from non-configurable, and see if there is any feedback from other one.
>
>
>
> Glad to
Hi Ard
That is a good question.
We (Intel) discussed this internally.
We do not know if there is any need to make it configurable, so we start from
non-configurable, and see if there is any feedback from other one.
Glad to hear your voice. We can define a policy like below: (I borrow some
defin
On 26 January 2017 at 08:39, Jiewen Yao wrote:
> If the UEFI image is page aligned, the image code section is set to read
> only and the image data section is set to non-executable.
>
> 1) This policy is applied for all UEFI image including boot service driver,
> runtime driver or application.
> 2
2/3/4 looks good to me
Reviewed-by: Feng Tian
Thanks
Feng
-Original Message-
From: Ni, Ruiyu
Sent: Monday, February 6, 2017 2:01 PM
To: edk2-devel@lists.01.org
Cc: Fan, Jeff ; Tian, Feng
Subject: [PATCH v2 2/6] MdeModulePkg/PciBus: Accept Spec values as BarIndex and
Alignment
PI spe
Reviewed-by: Liming Gao
>-Original Message-
>From: Ni, Ruiyu
>Sent: Monday, February 06, 2017 2:01 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming ; Fan, Jeff
>Subject: [PATCH v2 6/6] MdePkg/Pci22.h: Deprecate out-of-Spec
>IncompatiblePciDevice macros
>
>DEVICE_ID_NOCARE is defined as 0
24 matches
Mail list logo
