Re: [edk2] UEFI HTTP Boot Device Path and DNS

Hi Michael, Sorry I missed your previous email. First, I don't use OVMF platform, though I think the PXE and HTTP should be able to co-work together. It means that the PXE boot option and HTTP boot option are both available in the boot manager of BDS. I might not fully understand your usage, t

[edk2] [PATCH 0/2] Follow PI1.4a to fix artificial limitation of PCD SkuId range

There is absolutely no reason to artificially limit the SKU range to 1-255. PI1.4a spec fixed the artificial limitation. The patches are to follow PI1.4a spec to remove the sentence "The valid SkuId range is 1 to 255." from SetSku function comments, PCD_MAX_SKU_ID definition, the check to PCD_MAX_

[edk2] [PATCH 2/2] MdePkg: Follow PI1.4a to fix artificial limitation of SkuId range

There is absolutely no reason to artificially limit the SKU range to 1-255. PI1.4a spec fixed the artificial limitation. This patch is to follow PI1.4a spec to remove PCD_MAX_SKU_ID definition, the check to PCD_MAX_SKU_ID and the comments describes the limitation. Cc: Liming Gao Contributed-unde

[edk2] [PATCH 1/2] MdeModulePkg PCD: Follow PI1.4a to fix artificial limitation of SkuId range

There is absolutely no reason to artificially limit the SKU range to 1-255. PI1.4a spec fixed the artificial limitation. This patch is to follow PI1.4a spec to remove the sentence "The valid SkuId range is 1 to 255." from SetSku function comments. Cc: Liming Gao Contributed-under: TianoCore Cont

[edk2] [PATCH] MdePkg: Follow PI1.4a to update the comments of EndOfDxe and SmmReadyToLock

Cc: Jiewen Yao Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- MdePkg/Include/Protocol/DxeSmmReadyToLock.h | 26 +++--- MdePkg/Include/Protocol/SmmEndOfDxe.h | 14 +- MdePkg/Include/Protocol/SmmReadyToLock

Re: [edk2] [Patch] ShellPkg: Add argument to set block size for tftp command.

On 20 May 2016 at 08:24, Fu, Siyuan wrote: > Hi, Ard > > > > Thanks for you reminder. I’m sorry that I don’t have the ARM build > environment, will try to setup one later. For the current build failure, do > you mean the explicit casting in attached patch could fix it? > Yes. I tried your patch a

Re: [edk2] [Patch] ShellPkg: Add argument to set block size for tftp command.

Hi, Ard Thanks for you reminder. I’m sorry that I don’t have the ARM build environment, will try to setup one later. For the current build failure, do you mean the explicit casting in attached patch could fix it? Best Regards Siyuan From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent:

Re: [edk2] [Patch] ShellPkg: Add argument to set block size for tftp command.

This patch has broken the build on ARM In function 'DownloadFile': :938:22: error: pointer targets in assignment differ in signedness [-Werror=pointer-sign] ReqOpt.Optio

Re: [edk2] [PATCH] Vlv2TbltDevicePkg: Fixed an Array overflow issue. Remove some useless debug message.

Reviewed-by: zwei4 Thanks, David Intel SSG BIOS -Original Message- From: Guo, Mang Sent: Friday, May 20, 2016 1:33 PM To: edk2-devel@lists.01.org Cc: Wei, David Subject: [PATCH] Vlv2TbltDevicePkg: Fixed an Array overflow issue. Remove some useless debug message. Contributed-und

Re: [edk2] [PATCH 0/2] Add Erase Block Protocol support for UFS devices

Looks good to me Reviewed-by: Feng Tian Thanks Feng -Original Message- From: Wu, Hao A Sent: Monday, May 9, 2016 11:39 AM To: edk2-devel@lists.01.org; Tian, Feng Cc: Wu, Hao A Subject: [PATCH 0/2] Add Erase Block Protocol support for UFS devices This patch series add the Erase Block

[edk2] [PATCH] Vlv2TbltDevicePkg: Fixed an Array overflow issue. Remove some useless debug message.

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Guo Mang --- Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c | 14 +++--- .../Library/DxeEsrtCapsuleBsLib/DxeCapsuleLib.c | 20 2 files changed, 7 insertions(+), 27 deletions(-) diff --g

Re: [edk2] [BaseTools] RuleOverride = BINARY code location?

> On May 19, 2016, at 8:18 PM, Gao, Liming wrote: > > Thanks Andrew. I will continue to investigate it. > >>> F = 'FileNoExtention' >>> os.path.splitext(F)[1] '' >>> '' in '.out' True So I think the bug is the `in` it should be `==` >>> '' == '.out' False Thanks, Andrew Fish >> -Orig

[edk2] [PATCH] Vlv2TbltDevicePkg: Fixed an Array overflow issue. Remove some useless debug message.

--- Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c | 14 +++--- .../Library/DxeEsrtCapsuleBsLib/DxeCapsuleLib.c | 20 2 files changed, 7 insertions(+), 27 deletions(-) diff --git a/Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c b/Vlv2TbltDevicePkg/FvbRuntime

Re: [edk2] UEFI HTTP Boot Device Path and DNS

Gently ping .. Could anyone help to provide insights for this? In short the URI is absoultely legit to have host name in it but current device path couldn't provide any dns server to help in resolving it. How to deal with this problem ? Thanks, Michael On Tue, Apr 19, 2016 at 06:18:35PM +0800, M

Re: [edk2] [PATCH v2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc

Reviewed-by: Fu Siyuan > -Original Message- > From: Gary Lin [mailto:g...@suse.com] > Sent: Friday, May 20, 2016 11:18 AM > To: edk2-devel@lists.01.org > Cc: Wu, Jiaxin ; Fu, Siyuan ; El- > Haj-Mahmoud, Samer ; Laszlo Ersek > ; Hegde, Nagaraj P > Subject: [PATCH v2] NetworkPkg/HttpDxe:

Re: [edk2] [PATCH v2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc

Reviewed-By: Wu Jiaxin > -Original Message- > From: Gary Lin [mailto:g...@suse.com] > Sent: Friday, May 20, 2016 11:18 AM > To: edk2-devel@lists.01.org > Cc: Wu, Jiaxin ; Fu, Siyuan ; El- > Haj-Mahmoud, Samer ; Laszlo Ersek > ; Hegde, Nagaraj P > Subject: [PATCH v2] NetworkPkg/HttpDxe:

[edk2] [PATCH v2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc

The HTTP Token Wrap is created in EfiHttpResponse() and then passed to the deferred Receive event callback, HttpTcpReceiveNotifyDpc. HttpTcpReceiveHeader and HttpTcpReceiveBody use a Tcp polling loop to monitor the socket status and trigger the Receive event when a new packet arrives. The Receive e

Re: [edk2] [BaseTools] RuleOverride = BINARY code location?

Thanks Andrew. I will continue to investigate it. > -Original Message- > From: af...@apple.com [mailto:af...@apple.com] > Sent: Friday, May 20, 2016 10:01 AM > To: Gao, Liming > Cc: edk2-devel > Subject: Re: [edk2] [BaseTools] RuleOverride = BINARY code location? > > > > On May 18, 20

Re: [edk2] [PATCH 1/2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc

On Fri, May 20, 2016 at 12:21:39AM +, Wu, Jiaxin wrote: > Gary, good catching! Wrap->TcpWrap.IsRxDone is invalid if it's freed in > HttpTcpReceiveNotifyDpc. But, if you remove it directly, Wrap will not be > freed for each TcpReceive in your patch. Actually, we should free it before > return

[edk2] [PATCH v2] MdeModulePkg/DisplayEngine: Fix memory leak issues in DisplayEngine

The following codes are useless and cause memory leak issues. So now remove them. Cc: Cecil Sheng Cc: Qiu Shumin Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi --- MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c | 5 + MdeModulePkg

Re: [edk2] [patch] NetworkPkg: Refine codes of Http boot driver.

Hi Samer I agree with you to keep DEBUG message and add a another "Download failed "message to give user a hint, as for adding a URL where the file is being downloaded, But we already print it in the HttpBootClient.c file Best Regards Lubo -Original Message- From: Fu, Siyuan

Re: [edk2] [patch] NetworkPkg: Refine codes of Http boot driver.

Hi, Samer I think in PXE this issue was solved by the EFI_PXE_BASE_CODE_CALLBACK_PROTOCOL, which allows the platform owner to provide an callback implementation which will take precedence over the default implementation in PXE driver. The callback protocol allows the platform owner to display

Re: [edk2] edk2-staging/HTTPS-TLS

Thanks all of your points. So, option 1 is preferred (Keep the liner commit history). And I agree to regular sync edk2-staging/master to latest edk2/master automatically, but not for each feature branch's rebase. Jordan, If no objection, can you help to set up this regular sync between edk2-sta

Re: [edk2] [BaseTools] RuleOverride = BINARY code location?

> On May 18, 2016, at 5:44 PM, Andrew Fish wrote: > >> >> On May 18, 2016, at 5:43 PM, Gao, Liming wrote: >> >> Andrew: >> |.bin will search the file with the postfix .bin in INF file directory and >> its output directory. So, there may be more than .bin files are found. >> Please see the c

Re: [edk2] [patch] NetworkPkg: Refine codes of Http boot driver.

Thanks Siyuan, I will improve the codes. lubo From: Fu, Siyuan Sent: Friday, May 20, 2016 9:19 AM To: Zhang, Lubo ; edk2-devel@lists.01.org Cc: Ye, Ting ; Wu, Jiaxin Subject: RE: [patch] NetworkPkg: Refine codes of Http boot driver. And I think the "percentage" is what you actually means by the

Re: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Remove the status check of SockProcessRcvToken

Reviewed-by: Fu Siyuan > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Gary Lin > Sent: Thursday, May 19, 2016 11:49 AM > To: edk2-devel@lists.01.org > Cc: Fu, Siyuan ; Wu, Jiaxin > Subject: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Remove the

Re: [edk2] [patch] NetworkPkg: Refine codes of Http boot driver.

And I think the "percentage" is what you actually means by the name "Ratio". From: Fu, Siyuan Sent: Friday, May 20, 2016 9:17 AM To: Zhang, Lubo ; edk2-devel@lists.01.org Cc: Ye, Ting ; Wu, Jiaxin Subject: RE: [patch] NetworkPkg: Refine codes of Http boot driver. Hi, Lubo 1. The (ReceivedSize *

Re: [edk2] [patch] NetworkPkg: Refine codes of Http boot driver.

Hi, Lubo 1. The (ReceivedSize * 100) may lead to a integer overflow, especially in a 32bit system. 2. You could use %[wide]d to control the width of the print, to avoid the if condition "Ratio>10" Best Regards Siyuan > -Original Message- > From: Zhang, Lubo > Sent: Thursday, May 19, 20

[edk2] [PATCH] MdePkg/WSMT.h: update header comment to use official URL link.

Update WSMT table link to official MSDN URL. Cc: Michael D Kinney Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao --- MdePkg/Include/IndustryStandard/WindowsSmmSecurityMitigationTable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [edk2] [patch] MdeModulePkg/DisplayEngine: Fix memory leak issues in DisplayEngine

Hi Cecil, Thanks for your comments! I agree with you proposal. Hi All, I will send a new patch to remove the useless code. Please ignore this one! Thanks, Dandan -Original Message- From: Sheng, Cecil (HPS SW) [mailto:cecil.sh...@hpe.com] Sent: Friday, May 20, 2016 7:52 AM To: Bi, Dan

Re: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Remove the status check of SockProcessRcvToken

MdeModulePkg\Universal\Network\Tcp4Dxe has the same issue, I will provide another patch to fix it also. Thanks, Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Wu, Jiaxin > Sent: Friday, May 20, 2016 8:31 AM > To: Gary Lin ; edk2-dev

Re: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Remove the status check of SockProcessRcvToken

Reviewed-By: Wu Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Gary Lin > Sent: Thursday, May 19, 2016 11:49 AM > To: edk2-devel@lists.01.org > Cc: Fu, Siyuan ; Wu, Jiaxin > Subject: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Remove the

Re: [edk2] [PATCH 1/2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc

Gary, good catching! Wrap->TcpWrap.IsRxDone is invalid if it's freed in HttpTcpReceiveNotifyDpc. But, if you remove it directly, Wrap will not be freed for each TcpReceive in your patch. Actually, we should free it before return HttpResponseWorker. // // We still need receive mo

Re: [edk2] [patch] MdeModulePkg/DisplayEngine: Fix memory leak issues in DisplayEngine

Hi Dandan, The InputHandle.c one looks good. About the ProcessOptions.c one, I propose remove the lines starting "FreePool (StringPtr)", the following "if (EFI_ERROR (Status))" because it's useless, and the "return Status" line. Then the clean-up block at the end of function frees the strings.

Re: [edk2] [RFC] Structured PCD Proposal

> On May 19, 2016, at 12:16 PM, Kinney, Michael D > wrote: > > Andrew, > > My responses embedded below. > Mike, Likewise. > Mike > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Andrew Fish >> Sent: Thursday, May 19, 2016 10:53

Re: [edk2] [PATCH v1 1/1] ShellPkg/App: Fix memory leak and save resources.

Marvin, I will review your patches this week. -Jaben > -Original Message- > From: Marvin Häuser [mailto:marvin.haeu...@outlook.com] > Sent: Thursday, May 19, 2016 1:20 PM > To: edk2-devel@lists.01.org > Cc: Carsey, Jaben > Subject: RE: [edk2] [PATCH v1 1/1] ShellPkg/App: Fix memory leak

Re: [edk2] [PATCH v1 1/1] ShellPkg/App: Fix memory leak and save resources.

Hey Jaben, As I mentioned in 3), there is still the CreateFileInterfaceMem() resource leak if the list is not empty, so this is definitely still a todo, I do not know how to solve (yet?). I only kept the ASSERT() because it was present before, I don't really see the point in stopping execution

Re: [edk2] [PATCH v1 1/1] ShellPkg/App: Fix memory leak and save resources.

Can we safely remove the ASSERt now? > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Marvin Häuser > Sent: Thursday, May 19, 2016 12:04 PM > To: edk2-devel@lists.01.org > Cc: Carsey, Jaben ; Qiu, Shumin > > Subject: [edk2] [PATCH v1 1/1] She

Re: [edk2] [RFC] Structured PCD Proposal

Andrew, My responses embedded below. Mike > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew > Fish > Sent: Thursday, May 19, 2016 10:53 AM > To: Kinney, Michael D ; edk2-devel@lists.01.org > de...@ml01.01.org> > Subject: Re: [edk2] [R

Re: [edk2] System Table and more

Thank you Andrew, Laszlo, and Jaben for the answers. They were very informative and I believe I have enough information to continue developing my application. Have a good day, Aaron Viviano Spacelabs Healthcare -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Thurs

Re: [edk2] [PATCH v1 1/1] ShellPkg/App: Fix memory leak and save resources.

Hello, Please excuse this E-Mail, I accidentially CC'd the maintainers of the wrong package. The patch has been re-sent with the correct CCs. Regards, Marvin. Von: edk2-devel im Auftrag von Marvin Häuser Gesendet: Donnerstag, 19. Mai 2016 21:02 An: ed

[edk2] [PATCH v1 1/1] ShellPkg/App: Fix memory leak and save resources.

1) RunSplitCommand() allocates the initial SplitStdOut via CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix the memory leak. 2) In RunSplitCommand(), SplitStdOut is checked for equality with StdIn. This cannot happen due to the if-check within the swap. Hence remove it.

[edk2] [PATCH v1 1/1] ShellPkg/App: Fix memory leak and save resources.

1) RunSplitCommand() allocates the initial SplitStdOut via CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix the memory leak. 2) In RunSplitCommand(), SplitStdOut is checked for equality with StdIn. This cannot happen due to the if-check within the swap. Hence remove it.

Re: [edk2] [RFC] Proposal to organize packages into directories

On 19/05/2016 20:21, Kinney, Michael D wrote: > Paolo, > > For this proposal, I am not only looking at existing packages/modules/libs, I > am also considering where new content might go over time. For example, the > MdeModulePkg has grown in size over the years. The PEI Core, DXE Core, SMM >

Re: [edk2] [RFC] Proposal to organize packages into directories

Paolo, For this proposal, I am not only looking at existing packages/modules/libs, I am also considering where new content might go over time. For example, the MdeModulePkg has grown in size over the years. The PEI Core, DXE Core, SMM Core content in MdeModulePkg is "Core" content, but much of

Re: [edk2] [RFC] Structured PCD Proposal

> On May 19, 2016, at 2:26 AM, Laszlo Ersek wrote: > > On 05/19/16 01:28, Kinney, Michael D wrote: > > [snip] > >> ## C Structure Syntax Proposal >> * Use C typedef syntax to describe complex C structures >> * Use a C language parser with support for struct/union/array/bit >> fields/pack >>

Re: [edk2] [RFC] Structured PCD Proposal

> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo > Ersek > Sent: Thursday, May 19, 2016 2:26 AM > To: Kinney, Michael D > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [RFC] Structured PCD Proposal > > On 05/19/16 01:28, Kinney, M

Re: [edk2] [RFC] Proposal to organize packages into directories

On 19/05/2016 18:21, Kinney, Michael D wrote: > This is one of the reasons I wanted to have both a "Silicon" and a "Driver" > top level directory. > > We can change names, but the idea is that the "Silicon" one would contains > CPU/Chipset/SoC content that is usually contains the drivers to in

Re: [edk2] Acquire the permission to commit code in edk2-staging tree

Hi Abner, I see you have set up a fork of edk2-staging at: https://github.com/AbnerChang/edk2-staging Can you add your new RISC-V branch in this fork first? This will give you a chance to prepare content in your own fork that follows the edk2 process. One of the maintainers, such as Jordan or

Re: [edk2] [RFC] Proposal to organize packages into directories

Paolo, This is one of the reasons I wanted to have both a "Silicon" and a "Driver" top level directory. We can change names, but the idea is that the "Silicon" one would contains CPU/Chipset/SoC content that is usually contains the drivers to init the CPU complex, turn on caches, enable memory

Re: [edk2] [RFC] Proposal to organize packages into directories

On 19/05/2016 18:03, Ryan Harkin wrote: > > IA32X64 is not a great name, but neither is Intel. X86 suggests 32-bit > > only. > > I prefer the idea of separating by vendor. One vendor may have > multiple architectures, for example. That's exactly why I want to separate by architecture. :) When

Re: [edk2] [RFC] Proposal to organize packages into directories

On 19 May 2016 at 14:35, Paolo Bonzini wrote: > > > On 18/05/2016 01:57, Kinney, Michael D wrote: >> Core >> CorebootModulePkg >> CorebootPayloadPkg > > I think that anything with a .fdf file should be under Platform. > CorebootPayloadPkg is the only outlier in your proposal. > >> Em

Re: [edk2] Using the Shell to launch a kernel using a RAMDISK

Yes this works, A simple checkbox in the HII form before starting File Explorer -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo Ersek Sent: Thursday, May 19, 2016 2:49 AM To: Tian, Feng ; El-Haj-Mahmoud, Samer ; Andrew Fish ; Foster, Matt

Re: [edk2] Acquire the permission to commit code in edk2-staging tree

So, I think I can be the owner at the beginning, says I can own the RISC-V package and keep to sync with EDK2. However, I think it would be better to have the co-owner, probably Jordan or Jiewen. I am not really clear about the entire process of edk2 code commitment, just my first priority for R

Re: [edk2] [patch] NetworkPkg: Refine codes of Http boot driver.

Thanks Zhang. I know this makes sense (and does help during lengthy download), and I also know that PXE does something similar. I am only concerned about this happening after BGRT logo is displayed on the screen (if PXE/HTTP boot options are tried after a failed HDD boot option for instance). T

Re: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Remove the status check of SockProcessRcvToken

Reviewed-by: Samer El-Haj-Mahmoud -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gary Lin Sent: Wednesday, May 18, 2016 10:49 PM To: edk2-devel@lists.01.org Cc: Siyuan Fu ; Jiaxin Wu Subject: [edk2] [PATCH 2/2] NetworkPkg/TcpDxe: Remove the stat

Re: [edk2] [PATCH 1/2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc

Thanks for the fixes Gary Reviewed-by: Samer El-Haj-Mahmoud -Original Message- From: Gary Lin [mailto:g...@suse.com] Sent: Wednesday, May 18, 2016 10:49 PM To: edk2-devel@lists.01.org Cc: Wu, Jiaxin ; Siyuan Fu ; El-Haj-Mahmoud, Samer ; Laszlo Ersek ; Hegde, Nagaraj P Subject: [PATC

Re: [edk2] [PATCH 1/2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc

Interesting (and accurate) deduction... :) -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gary Lin Sent: Thursday, May 19, 2016 5:07 AM To: Laszlo Ersek Cc: edk2-de...@ml01.01.org; Wu, Jiaxin ; Siyuan Fu Subject: Re: [edk2] [PATCH 1/2] Network

Re: [edk2] [RFC] Proposal to organize packages into directories

On 18/05/2016 01:57, Kinney, Michael D wrote: > Core > CorebootModulePkg > CorebootPayloadPkg I think that anything with a .fdf file should be under Platform. CorebootPayloadPkg is the only outlier in your proposal. > Emulated > DuetPkg > EmulatorPkg > Nt32Pkg >

Re: [edk2] edk2-staging/HTTPS-TLS

I do have some experience maintaining my branches (in other projects) that eventually get submitted as pull requests to a master. And I always find it easier to keep my branch in sync by doing frequent merge form master. I agree that it probably makes more sense to do this a couple of times a we

Re: [edk2] [Patch] MdeModulePkg/PciHostBridgeDxe: Add CpuArch protocol dependency

On 19 May 2016 at 13:04, Laszlo Ersek wrote: > On 05/19/16 12:22, Ard Biesheuvel wrote: >> On 19 May 2016 at 12:04, Laszlo Ersek wrote: > >>> On the other hand... the virtio-gpu device would require a GOP that is >>> Blt()-only. That is, no direct framebuffer access. I very much hope this >>> is

[edk2] [patch] MdeModulePkg/DisplayEngine: Fix memory leak issues in DisplayEngine

Cc: Qiu Shumin Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi Reviewed-by: Eric Dong --- MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c | 5 + MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c | 3 ++- 2 files changed, 3 inse

Re: [edk2] [Patch] MdeModulePkg/PciHostBridgeDxe: Add CpuArch protocol dependency

On 05/19/16 12:22, Ard Biesheuvel wrote: > On 19 May 2016 at 12:04, Laszlo Ersek wrote: >> On the other hand... the virtio-gpu device would require a GOP that is >> Blt()-only. That is, no direct framebuffer access. I very much hope this >> is not a problem for the edk2 code. I don't know if boot

Re: [edk2] edk2-staging/HTTPS-TLS

On 05/19/16 11:53, Gao, Liming wrote: > Ersek: > I remember we discuss Rebase or Merge before. The conclusion is to > keep the liner history in edk2 project. So, I think rebase is better. Okay. > If we choose option 1, I suggest to setup mirror task in server and > auto run regular sync. If the c

Re: [edk2] [Patch] MdeModulePkg/PciHostBridgeDxe: Add CpuArch protocol dependency

On 19 May 2016 at 12:04, Laszlo Ersek wrote: > On 05/19/16 10:52, Ni, Ruiyu wrote: >> >> >> Regards, >> Ray >> >>>-Original Message- >>>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >>>Laszlo Ersek >>>Sent: Thursday, May 19, 2016 4:08 PM >>>To: Ni, Ruiyu ; edk2-de

Re: [edk2] Acquire the permission to commit code in edk2-staging tree

Jordan: I think the package maintainer has the access. The staging branch owner may not have. So, if the contributor has no access, he needs to ask help for the package maintainer. If it is TRUE, could you help update README to document it? Thanks Liming > -Original Message- > From: Ju

Re: [edk2] [PATCH 1/2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc

On Thu, May 19, 2016 at 11:53:59AM +0200, Laszlo Ersek wrote: > On 05/19/16 10:39, Gary Lin wrote: > > Cc Samer and Nagaraj. > > I saw them with "git sent-email --dry-run". Wonder how they were dropped. > > They were not dropped. The list software is trying to be smart. > > Namely, if you go to <

Re: [edk2] [Patch] MdeModulePkg/PciHostBridgeDxe: Add CpuArch protocol dependency

On 05/19/16 10:52, Ni, Ruiyu wrote: > > > Regards, > Ray > >>-Original Message- >>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo >>Ersek >>Sent: Thursday, May 19, 2016 4:08 PM >>To: Ni, Ruiyu ; edk2-de...@ml01.01.org >>Cc: Gao, Liming >>Subject: Re: [edk2

Re: [edk2] [PATCH] OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM

On 05/19/16 10:42, Ni, Ruiyu wrote: > I agree. > > Reviewed-by: Ruiyu Ni Thanks Ray! I'll await Jordan's feedback too. Cheers! Laszlo >>-Original Message- >>From: Laszlo Ersek [mailto:ler...@redhat.com] >>Sent: Thursday, May 19, 2016 3:38 PM >>To: Ni, Ruiyu ; edk2-devel-01 >>Cc: Just

Re: [edk2] [PATCH 1/2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc

On 05/19/16 10:39, Gary Lin wrote: > Cc Samer and Nagaraj. > I saw them with "git sent-email --dry-run". Wonder how they were dropped. They were not dropped. The list software is trying to be smart. Namely, if you go to , and click "Unsubscribe or

Re: [edk2] edk2-staging/HTTPS-TLS

Ersek: I remember we discuss Rebase or Merge before. The conclusion is to keep the liner history in edk2 project. So, I think rebase is better. If we choose option 1, I suggest to setup mirror task in server and auto run regular sync. If the confliction happens, it sends the mail to edk dev li

Re: [edk2] [RFC] Structured PCD Proposal

Ersek: I add my comments. Thanks Liming > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Laszlo Ersek > Sent: Thursday, May 19, 2016 5:26 PM > To: Kinney, Michael D > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [RFC] Structured PCD

Re: [edk2] [PATCH 1/2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc

On 05/19/16 10:35, Gary Lin wrote: > On Thu, May 19, 2016 at 10:01:16AM +0200, Laszlo Ersek wrote: >> On 05/19/16 05:49, Gary Lin wrote: >>> The HTTP Token Wrap is created in EfiHttpResponse() and then passed >>> to the deferred Receive event callback, HttpTcpReceiveNotifyDpc. >>> HttpTcpReceiveHea

Re: [edk2] [Patch 0/7] Allocate aligned buffer for all semaphores

On 05/19/16 02:33, Michael Kinney wrote: > From Intel(R) 64 and IA-32 Architectures Software Developer's Manual, > one lock or semaphore is suggested to be present within a cache line. > If the processors are based on Intel NetBurst microarchitecture, two > cache lines are suggested. This could mi

Re: [edk2] [RFC] Structured PCD Proposal

On 05/19/16 01:28, Kinney, Michael D wrote: [snip] > ## C Structure Syntax Proposal > * Use C typedef syntax to describe complex C structures > * Use a C language parser with support for struct/union/array/bit > fields/pack > * Recommend use of libclang C language parser into Abstract Synt

[edk2] [Patch] Vlv2TbltDevicePkg: Update BIOS ID to V0.92.

Signed-off-by: lushifex --- Vlv2TbltDevicePkg/BiosIdD.env| 2 +- Vlv2TbltDevicePkg/BiosIdR.env| 2 +- Vlv2TbltDevicePkg/BiosIdx64D.env | 2 +- Vlv2TbltDevicePkg/BiosIdx64R.env | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Vlv2TbltDevicePkg/BiosIdD.env b/Vlv2TbltDe

Re: [edk2] [Patch] MdeModulePkg/PciHostBridgeDxe: Add CpuArch protocol dependency

Regards, Ray >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo >Ersek >Sent: Thursday, May 19, 2016 4:08 PM >To: Ni, Ruiyu ; edk2-de...@ml01.01.org >Cc: Gao, Liming >Subject: Re: [edk2] [Patch] MdeModulePkg/PciHostBridgeDxe: Add CpuArch

Re: [edk2] [PATCH] OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM

I agree. Reviewed-by: Ruiyu Ni >-Original Message- >From: Laszlo Ersek [mailto:ler...@redhat.com] >Sent: Thursday, May 19, 2016 3:38 PM >To: Ni, Ruiyu ; edk2-devel-01 >Cc: Justen, Jordan L >Subject: Re: [edk2] [PATCH] OvmfPkg: prevent 64-bit MMIO BAR degradation if >there is no CSM >

Re: [edk2] [PATCH 1/2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc

Cc Samer and Nagaraj. I saw them with "git sent-email --dry-run". Wonder how they were dropped. Gary Lin On Thu, May 19, 2016 at 11:49:17AM +0800, Gary Lin wrote: > The HTTP Token Wrap is created in EfiHttpResponse() and then passed > to the deferred Receive event callback, HttpTcpReceiveNotifyDp

Re: [edk2] [PATCH 1/2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc

On Thu, May 19, 2016 at 10:01:16AM +0200, Laszlo Ersek wrote: > On 05/19/16 05:49, Gary Lin wrote: > > The HTTP Token Wrap is created in EfiHttpResponse() and then passed > > to the deferred Receive event callback, HttpTcpReceiveNotifyDpc. > > HttpTcpReceiveHeader and HttpTcpReceiveBody use a Tcp p

Re: [edk2] edk2-staging/HTTPS-TLS

On 05/19/16 05:35, Wu, Jiaxin wrote: > Hi all, > There are two ways to sync HTTPS-TLS branch with EDK2 master: > > 1. Sync all changes in EDK2 master to branch by rebasing the whole > feature branch. Need frequency request to sync edk2-staging/master to > latest edk2/master. This way can also keep

Re: [edk2] [Patch] MdeModulePkg/PciHostBridgeDxe: Add CpuArch protocol dependency

On 05/19/16 09:17, Ruiyu Ni wrote: > The driver entry point calls gDS->SetMemorySpaceAttributes(). > This interface may return EFI_NOT_AVAILABLE_YET when CPU Arch > protocol is not available. > So we need to list CpuArch protocol in its INF dependency section. > > Contributed-under: TianoCore Cont

Re: [edk2] [PATCH 1/2] NetworkPkg/HttpDxe: Don't free Wrap in HttpTcpReceiveNotifyDpc

On 05/19/16 05:49, Gary Lin wrote: > The HTTP Token Wrap is created in EfiHttpResponse() and then passed > to the deferred Receive event callback, HttpTcpReceiveNotifyDpc. > HttpTcpReceiveHeader and HttpTcpReceiveBody use a Tcp polling loop to > monitor the socket status and trigger the Receive eve

Re: [edk2] Using the Shell to launch a kernel using a RAMDISK

On 05/19/16 04:41, Tian, Feng wrote: > Samer, > > I am ok to add an item/option to allow user choose ramdisk memory > type. But I don't know how to organize the form to show that > straightforwardly, for example, how to add an item for those chosen > by File Explorer. Look forward to see your patc

Re: [edk2] [Patch 2/2] PcAtChipsetPkg/PcRtc: get century RTC address in entry point

On 05/19/16 04:27, Ni, Ruiyu wrote: > Laszlo, > > My understanding is: you have concern why I only call > GetCenturyRtcAddress() in RTC driver’s entry point, but > don’t write the century value to CMOS. > Is my understanding correct? > > Because RTC’s entry point calls PcRtcInit(), which calls >

Re: [edk2] [PATCH] OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM

On 05/19/16 04:02, Ni, Ruiyu wrote: > Laszlo, > All are good except: can you use EfiCreateProtocolNotifyEvent() > exposed by UefiLib? I am aware of that function, but I dislike it. The reason I dislike it is that (in my opinion) its internal error handling is inferior. For the return values of gBS

Re: [edk2] [patch] NetworkPkg: Refine codes of Http boot driver.

Reviewed-by: Ye Ting -Original Message- From: Zhang, Lubo Sent: Thursday, May 19, 2016 11:53 AM To: edk2-devel@lists.01.org Cc: Ye, Ting ; Fu, Siyuan ; Wu, Jiaxin Subject: [patch] NetworkPkg: Refine codes of Http boot driver. When downloading a big image as ram disk iso,we can print

Re: [edk2] System Table and more

On 05/19/16 01:27, Andrew Fish wrote: > >> On May 18, 2016, at 2:57 PM, Laszlo Ersek wrote: >> >> And, the availability of all of the arch protocols implies (as far as I >> remember -- sorry I won't do a detailed tally now) that all gRT-> >> fields have been filled in with valid function poin

Re: [edk2] Driver dependency on boot

You can create ProtocolNotification function for gEfiCcidProtocolGuid in ccidboot driver. If so, you don't need add it into [Depex]. UefiLib EfiCreateProtocolNotifyEvent() API can help to create it. Thanks Liming > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01

[edk2] [Patch] MdeModulePkg/PciHostBridgeDxe: Add CpuArch protocol dependency

The driver entry point calls gDS->SetMemorySpaceAttributes(). This interface may return EFI_NOT_AVAILABLE_YET when CPU Arch protocol is not available. So we need to list CpuArch protocol in its INF dependency section. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni