On Fri, Mar 23, 2018 at 05:25:54PM +0800, Ard Biesheuvel wrote:
> On 22 March 2018 at 19:02, Heyi Guo wrote:
> > The code in SM750 driver treated the address returned from
> > PciIo->GetBarAttributes() as device address; this should be fixed
> > after edk2 commit dc080d3 since GetBarAttributes() r
a" instead of network
download to store the final target.
Thanks,
Heyi
On Fri, Mar 23, 2018 at 12:51:45PM +0800, Ni, Ruiyu wrote:
> On 3/20/2018 8:15 PM, Guo Heyi wrote:
> >I've no idea about how to use Driver; let me spend some time to learn
> >first
> >:)
>
Hi Leif, Ard,
Any comments for this series of patches?
Thanks,
Heyi
On Wed, Mar 21, 2018 at 09:03:06AM +0800, Heyi Guo wrote:
> For BAR address translation support was added to edk2 generic PciHostBridge by
> commit 74d0a33, now we can also use it for D03/D05 platforms.
> This series of patches
Ah, I made the change locally but forgot to send it out...
Now it is there :)
Thanks and regards,
Heyi
On Wed, Mar 28, 2018 at 03:37:19PM +0200, Ard Biesheuvel wrote:
> On 26 March 2018 at 10:25, Heyi Guo wrote:
> > Sm750Dxe is a generic PCIe device driver for SM750 VGA device, so it
> > is not
On Wed, Mar 28, 2018 at 10:43:41AM +0100, Ard Biesheuvel wrote:
> On 28 March 2018 at 02:05, Guo Heyi wrote:
> > Hi Leif, Ard,
> >
> > Any comments for this series of patches?
> >
>
> Hello Heyi,
>
> Thanks for sending these patches. Leif is at the plug
Hi Jian,
I excluded CpuArchAttributes == 0 on purpose, for I don't know the expected
behaviour of gCpu->SetMemoryAttributes() if CpuArchAttributes == 0. Does that
mean we need to keep the cache attribute and remove memory protection
attributes?
If so, then it seems we don't need the check at all.
to differentiate such situation.
> I think there's flaw in the interface design. But it's hard to change it now.
>
> Regards,
> Jian
>
>
> > -Original Message-
> > From: Guo Heyi [mailto:heyi@linaro.org]
> > Sent: Thursday, March 29, 201
t; > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, March 29, 2018 2:13 PM
> > To: Guo Heyi
> > Cc: Zeng, Star ; edk2-devel@lists.01.org; Yi Li
> > ; Renhao Liang ;
> > Dong, Eric ; Kinney, Michael D
> > ; Gao, Liming ; Yao,
> > Jiewen ;
Yes, it is https://github.com/iwishguo/edk2-non-osi/tree/patch-sm750-fix-v2
I just put in the cover letter :)
Thanks,
Heyi
On Fri, Mar 30, 2018 at 11:56:01AM +0100, Ard Biesheuvel wrote:
> On 29 March 2018 at 01:06, Guo Heyi wrote:
> > Ah, I made the change locally but forgot to se
Hi Ard,
Thanks for your time of reviewing the patches.
Please see my opinions below.
On Fri, Mar 30, 2018 at 05:40:20PM +0200, Ard Biesheuvel wrote:
> On 29 March 2018 at 02:20, Guo Heyi wrote:
> > On Wed, Mar 28, 2018 at 10:43:41AM +0100, Ard Biesheuvel wrote:
> >> On 28 M
Hi Ray and Leif,
Any comments?
On Mon, Mar 26, 2018 at 05:03:10PM +0800, Guo Heyi wrote:
> Thanks Ray.
>
> Does that mean we need build the dynamic command driver separately and store
> it
> in other media instead of UEFI fd image? Right now if I include the driver
> into
On Tue, Apr 03, 2018 at 02:25:30AM +, Yao, Jiewen wrote:
> I have a discussion with Star/Jian.
>
> The expectation for the CPU driver is to handle PageAttribute.
> The expectation for the platform driver is to use GetAttribute(), AND/OR
> attribute, then call SetAttribute().
Agree, "Get and
Hi Ard,
Any comments?
Anyway we can modify the code if you insist on using an intermediate CPU IO
address space.
Thanks,
Heyi
On Sat, Mar 31, 2018 at 09:37:47AM +0800, Guo Heyi wrote:
> Hi Ard,
>
> Thanks for your time of reviewing the patches.
> Please see my opinions below.
Thanks, I will test mm command and let you know the result.
Regards,
Heyi
On Fri, Apr 13, 2018 at 09:19:53AM +0200, Ard Biesheuvel wrote:
> On 13 April 2018 at 04:05, Guo Heyi wrote:
> > Hi Ard,
> >
> > Any comments?
> >
>
> Apologies for the delay. I have
and regards,
Heyi
On Mon, Apr 16, 2018 at 09:57:09PM +0800, Guo Heyi wrote:
> Thanks, I will test mm command and let you know the result.
>
> Regards,
>
> Heyi
>
> On Fri, Apr 13, 2018 at 09:19:53AM +0200, Ard Biesheuvel wrote:
> > On 13 April 2018 at 04:05, Gu
BTW, there is actually a bug with ATU configuration which will cause IO access
failure, and we need to apply an additional patch (this patch is generated after
PCI host bridge patch series) as attached to fix this.
Regards,
Heyi
On Tue, Apr 17, 2018 at 09:20:44AM +0800, Guo Heyi wrote:
> Hi
On Mon, Apr 16, 2018 at 01:33:56PM +0100, Leif Lindholm wrote:
> On Mon, Apr 02, 2018 at 10:51:53AM +0800, Guo Heyi wrote:
> > Hi Ray and Leif,
> >
> > Any comments?
> >
> >
> > On Mon, Mar 26, 2018 at 05:03:10PM +0800, Guo Heyi wrote:
> > > Thank
Hi folks,
In PxeBcImpl.c, we have IcmpErrorListenHandler which seems to process ICMP
errors. But in EfiPxeBcStart function, we can see
Private->IcmpErrorRcvToken.Event is only a common event and Ip4->Receive is
called to receive IP4 packets. So will IcmpErrorListenHandler receive all IP4
packe
On Fri, Dec 08, 2017 at 12:39:30AM +, Wu, Jiaxin wrote:
> Hi Gary,
>
> Agree to generate a formal patch. You can attach the reviewed-by tag at the
> same time.
>
> Can you help to file one Bugzilla for this issue?
No Problem.
>
> BTW, Do you need us commit the patch or by yourself?
Yes,
Hi Jiaxin,
We are still having our QA to finally verify the patches (including the ICMP
error listener bug fix), so I will post the formal patch after regression test
completes.
Regards,
Gary (Heyi Guo)
On Fri, Dec 08, 2017 at 10:04:20AM +0800, Guo Heyi wrote:
> On Fri, Dec 08, 2017 at
used to get ICMP error from IP layer, and the
> >>data will be copied to Mode->IcmpError. So, I think the RxData should be
> >>recycled.
> >>>Besides, EFI_IP_PROTO_ICMP should be also checked in the call function
> >>but currently it's not:
> >>>if
Hi Jiaxin,
Bug 812 has been created: https://bugzilla.tianocore.org/show_bug.cgi?id=812
The regression test has been completed on our platform and I'll post a formal
patch in minutes.
Regards,
Gary (Heyi Guo)
On Fri, Dec 08, 2017 at 02:00:05PM +0800, Guo Heyi wrote:
> Hi Jiaxin,
>
gt;
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Guo Heyi
> > Sent: Monday, December 11, 2017 6:43 PM
> > To: Wu, Jiaxin
> > Cc: Ni, Ruiyu ; Dong, Eric ; edk2-
> > de...@lists.01.org; Wu, Ji
On Wed, Dec 20, 2017 at 03:26:45PM +, Ard Biesheuvel wrote:
> On 20 December 2017 at 15:17, gary guo wrote:
> > On Wed, Dec 20, 2017 at 09:13:58AM +, Ard Biesheuvel wrote:
> >> Hi Heyi,
> >>
> >> On 20 December 2017 at 08:21, Heyi Guo wrote:
> >> > PCIe on some ARM platforms requires addr
On Thu, Dec 21, 2017 at 08:32:37AM +, Ard Biesheuvel wrote:
> On 21 December 2017 at 08:27, Guo Heyi wrote:
> > On Wed, Dec 20, 2017 at 03:26:45PM +, Ard Biesheuvel wrote:
> >> On 20 December 2017 at 15:17, gary guo wrote:
> >> > On Wed, Dec 20, 2017 at 09
On Thu, Dec 21, 2017 at 05:43:17PM +0800, Ni, Ruiyu wrote:
> On 12/20/2017 11:26 PM, Ard Biesheuvel wrote:
> >On 20 December 2017 at 15:17, gary guo wrote:
> >>On Wed, Dec 20, 2017 at 09:13:58AM +, Ard Biesheuvel wrote:
> >>>Hi Heyi,
> >>>
> >>>On 20 December 2017 at 08:21, Heyi Guo wrote:
>
gt;>
> >> On 21 December 2017 at 09:48, Ni, Ruiyu wrote:
> >>>
> >>> On 12/21/2017 5:14 PM, Guo Heyi wrote:
> >>>>
> >>>>
> >>>> On Thu, Dec 21, 2017 at 08:32:37AM +, Ard Biesheuvel wrote:
> >>>>>
On Wed, Jan 17, 2018 at 02:08:06PM +, Ard Biesheuvel wrote:
> On 15 January 2018 at 14:46, Heyi Guo wrote:
> > This is the draft patch for the discussion posted in edk2-devel
> > mailing list:
> > https://lists.01.org/pipermail/edk2-devel/2017-December/019289.html
> >
> > As discussed in the m
Sorry for the late; I caught cold and didn't work for several days last week :(
Please see my comments below:
On Mon, Jan 22, 2018 at 11:36:14AM +0800, Ni, Ruiyu wrote:
> On 1/18/2018 9:26 AM, Guo Heyi wrote:
> >On Wed, Jan 17, 2018 at 02:08:06PM +, Ard Biesheuvel wrote:
>
to:ard.biesheu...@linaro.org]
> >>> Sent: Friday, February 2, 2018 4:22 PM
> >>> To: Ni, Ruiyu
> >>> Cc: Guo Heyi ,Dong Wei ; Dong,
> >>> Eric ; edk2-devel@lists.01.org; linaro-uefi >>> u...@lists.linaro.org>; Kinney, Michael D ;
> >
On Thu, Feb 08, 2018 at 04:02:39PM +, Ard Biesheuvel wrote:
> On 8 February 2018 at 16:01, Haojian Zhuang wrote:
> > On 7 February 2018 at 01:29, Leif Lindholm wrote:
> >> On Mon, Feb 05, 2018 at 04:25:52PM +0800, Haojian Zhuang wrote:
> >>> Add skeleton of HiKey960 platform.
> >>>
> >>> Cont
Hi Haojian,
Dw8250SerialPortRuntimeLib actually depends on DW8250 hardware IP; if there
isn't such device on Hikey, then you can't use this library instance indeed.
But I think PeiDxeDebugLibReportStatusCode should be some common code, however
it depends on ReportStatusCodeLib and Status Code PEI
On Tue, Feb 13, 2018 at 12:59:50AM +, Haojian Zhuang wrote:
> On 02/13/2018 08:23 AM, Guo Heyi wrote:
> > Hi Haojian,
> >
> > Dw8250SerialPortRuntimeLib actually depends on DW8250 hardware IP; if there
> > isn't such device on Hikey, then you can&#x
Thanks Ray and Laszlo; I think I'd better refine comments and commit message
first, or it is rather confusing for review.
I'll send v3 ASAP.
Regards,
Gary
On Thu, Feb 22, 2018 at 11:06:13AM +0100, Laszlo Ersek wrote:
> On 02/22/18 07:54, Heyi Guo wrote:
> > v2:
> > Changs are made according to t
On Thu, Feb 22, 2018 at 11:41:50AM +0100, Laszlo Ersek wrote:
> On 02/22/18 07:54, Heyi Guo wrote:
> > PciIo::GetBarAttributes should return CPU view address according to
> > UEFI spec 2.7, so we change the implementation to follow the spec.
> >
> > Contributed-under: TianoCore Contribution Agreem
Hi Jeremy,
This TF binaries have not been patched the latest SMCCC workaround; it is based
on v1.4 release and was only
patched with "disable/enable MMU in PSCI SMC call", as the commit in upstream TF
code:
f62ad322695d16178db464dc062fe0af592c6780
When we generated these binaries, SMCCC patches
On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:
> Thanks for writing up the details!
>
> Comments:
>
> On 02/23/18 09:53, Heyi Guo wrote:
> > PCI address translation is necessary for some non-x86 platforms. On
> > such platforms, address value (denoted as "device address" or "addres
On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:
> Thanks for writing up the details!
>
> Comments:
>
> On 02/23/18 09:53, Heyi Guo wrote:
> > PCI address translation is necessary for some non-x86 platforms. On
> > such platforms, address value (denoted as "device address" or "addres
On Fri, Feb 23, 2018 at 09:02:46AM +, Ard Biesheuvel wrote:
> On 23 February 2018 at 03:17, Guo Heyi wrote:
> > Hi Jeremy,
> >
> > This TF binaries have not been patched the latest SMCCC workaround; it is
> > based
> > on v1.4 release and was only
> > p
On Sat, Feb 24, 2018 at 11:11:35AM +0800, Ni, Ruiyu wrote:
> On 2/24/2018 9:51 AM, Guo Heyi wrote:
> >On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:
> >>Thanks for writing up the details!
> >>
> >>Comments:
> >>
> >>On 02/23/18
Hi folks,
In BmDriverHealth.c, function BmRepairAllControllers may recursively call itself
if some driver health protocol returns EfiDriverHealthStatusReconnectRequired.
However, if there is something wrong in some 3rd party driver (e.g. PCI oprom),
the driver health protocol of that driver may al
On Sat, Feb 24, 2018 at 04:20:52PM +0800, Ni, Ruiyu wrote:
> On 2/24/2018 2:23 PM, Guo Heyi wrote:
> >Hi folks,
> >
> >In BmDriverHealth.c, function BmRepairAllControllers may recursively call
> >itself
> >if some driver health protocol returns
> >
Sure.
On Sat, Feb 24, 2018 at 08:40:20AM +, Ni, Ruiyu wrote:
> Will you submit a patch for this change?
>
> Thanks/Ray
>
> > -Original Message-----
> > From: Guo Heyi [mailto:heyi@linaro.org]
> > Sent: Saturday, February 24, 2018 4:29 PM
> > To
On Sat, Feb 24, 2018 at 04:30:42PM +0800, Ni, Ruiyu wrote:
> On 2/24/2018 11:59 AM, Guo Heyi wrote:
> >On Sat, Feb 24, 2018 at 11:11:35AM +0800, Ni, Ruiyu wrote:
> >>On 2/24/2018 9:51 AM, Guo Heyi wrote:
> >>>On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrot
Hi Peter,
Thanks for your detailed explanation. I still have one question:
On normal platforms, there are more boot options created by UEFI other than the
hard disk boot option created by OS installation, like PXE network boot, USB
stick boot, etc. If we use the PlatformRecovery method, will
Hi Sunny,
I didn't consider it as a value necessary for platform override, for the retry
count should only have some impact on boot performance and it only happens when
there is something wrong.
May I know what value you will use for your platform and why?
Thanks and regards,
Gary (Heyi Guo)
O
Hi Laszlo,
I agree the current patch makes the code ugly, and turning the logic into a
normal loop should be the perfect solution. If Ray also agrees on it, I can try
to do that.
Thanks and regards,
Heyi
On Mon, Feb 26, 2018 at 05:23:29PM +0100, Laszlo Ersek wrote:
> On 02/26/18 09:29, Heyi Guo
Hi Ard,
Sorry for the late of seeing this patch. I have one question: why don't we
implement a runtime serial port lib, which will switch UART base address in
virtual address map change? I think this will be useful when we want to debug
runtime driver in OS stage. And if we have a runtime version
Hi Laszlo,
Just a note that comment [6] has not been fully applied in my RFC v4, that I
didn't touch the outer ALIGN_VALUE() yet. As you said, it is an independent
issue and I think it can be fixed before or after my proposed change. I can do
something after Ray comments on it.
Regards,
Heyi
On
Hi Ray,
Thanks for your comments. It seems comments 10 and 12 are the major issue; let's
discuss that first.
1. In current implementation, namely PciBusDxe and PciHostBridgeDxe both in
MdeModulePkg, Address parameter passed to RootBridgeIoMemRead comes from
PciIoMemRead().
2. In PciIoMemRead(), O
Thanks Ray and Laszlo, I will create v2 according to your comments.
Regards,
Heyi
On Tue, Feb 27, 2018 at 11:29:18AM +0100, Laszlo Ersek wrote:
> On 02/27/18 06:48, Ni, Ruiyu wrote:
> > On 2/27/2018 8:48 AM, Guo Heyi wrote:
> >> Hi Laszlo,
> >>
> >> I agree t
On Tue, Feb 27, 2018 at 05:59:48PM +0800, Ni, Ruiyu wrote:
> On 2/27/2018 5:33 PM, Guo Heyi wrote:
> >Hi Ray,
> >
> >Thanks for your comments. It seems comments 10 and 12 are the major issue;
> >let's
> >discuss that first.
> >
> >
On Tue, Feb 27, 2018 at 11:43:35AM +0100, Laszlo Ersek wrote:
> On 02/27/18 10:23, Ard Biesheuvel wrote:
> > On 27 February 2018 at 01:50, Guo Heyi wrote:
> >> Hi Ard,
> >>
> >> Sorry for the late of seeing this patch. I have one question: why don't we
06:45:01PM +0800, Guo Heyi wrote:
> On Tue, Feb 27, 2018 at 05:59:48PM +0800, Ni, Ruiyu wrote:
> > On 2/27/2018 5:33 PM, Guo Heyi wrote:
> > >Hi Ray,
> > >
> > >Thanks for your comments. It seems comments 10 and 12 are the major issue;
> > >let&#
On Wed, Feb 28, 2018 at 03:25:03PM +0800, Ni, Ruiyu wrote:
> On 2/28/2018 10:29 AM, Ni, Ruiyu wrote:
> >On 2/27/2018 7:44 PM, Guo Heyi wrote:
> >>Hi all,
> >>
> >>I believe we have come to conclusion for major parts, so I'm going to
> >>send out
On Wed, Feb 28, 2018 at 10:39:24AM +0100, Laszlo Ersek wrote:
> On 02/28/18 08:53, Guo Heyi wrote:
> > On Wed, Feb 28, 2018 at 03:25:03PM +0800, Ni, Ruiyu wrote:
>
> >> Heyi,
> >> My understanding is this whole change is backward compatible.
> >> Which m
Sorry, forgot to add a "v2" mark in the subjuect prefix...
Regards,
Heyi
On Thu, Mar 01, 2018 at 10:39:32AM +0800, Heyi Guo wrote:
> Function BmRepairAllControllers may recursively call itself if some
> driver health protocol returns EfiDriverHealthStatusReconnectRequired.
> However, driver healt
Hi Ray,
I've one question about (9); please see it below:
On Tue, Feb 27, 2018 at 04:48:47PM +0800, Ni, Ruiyu wrote:
> On 2/27/2018 10:09 AM, Heyi Guo wrote:
> >PCI address translation is necessary for some non-x86 platforms. On
> >such platforms, address value (denoted as "device address" or "ad
Thanks; I got some trouble in making the subject short and clear :)
Regards,
Heyi
On Thu, Mar 01, 2018 at 11:20:22AM +0100, Laszlo Ersek wrote:
> On 03/01/18 07:57, Heyi Guo wrote:
> > Use ZeroMem to initialize all fields in temporary
> > PCI_ROOT_BRIDGE_APERTURE variables to zero. This is not ma
On Thu, Mar 01, 2018 at 11:17:30AM +0100, Laszlo Ersek wrote:
> Hello Heyi,
>
> On 03/01/18 07:57, Heyi Guo wrote:
> > Use ZeroMem to initialize all fields in temporary
> > PCI_ROOT_BRIDGE_APERTURE variables to zero. This is not mandatory but
> > is helpful for future extension: when we add new fi
On Fri, Mar 02, 2018 at 11:19:31AM +0100, Laszlo Ersek wrote:
> On 03/01/18 11:48, Guo Heyi wrote:
> > On Thu, Mar 01, 2018 at 11:17:30AM +0100, Laszlo Ersek wrote:
> >> On 03/01/18 07:57, Heyi Guo wrote:
>
> >>> diff --git a/OvmfPkg/Library/PciHostBridgeLib/XenS
Hi Ray,
Any comments for v5?
Regards,
Heyi
On Thu, Mar 01, 2018 at 02:57:22PM +0800, Heyi Guo wrote:
> PCI address translation is necessary for some non-x86 platforms. On
> such platforms, address value (denoted as "device address" or "address
> in PCI view") set to PCI BAR registers in configu
Hi Ray,
Sorry to disturb, but I didn't find the patch committed. Could you help to do
that?
Thanks,
Heyi
On Thu, Mar 01, 2018 at 12:46:32PM +0800, Ni, Ruiyu wrote:
> On 3/1/2018 10:39 AM, Heyi Guo wrote:
> >Function BmRepairAllControllers may recursively call itself if some
> >driver health pro
Thanks. Please let me know if any further changes are needed.
Regards,
Heyi
On Wed, Mar 07, 2018 at 12:30:59PM +0800, Ni, Ruiyu wrote:
> On 3/6/2018 10:44 AM, Guo Heyi wrote:
> >Hi Ray,
> >
> >Any comments for v5?
>
> Heyi,
> Some backward compatibility concer
Yes it is. Sorry for missing to do that. Will keep in mind next time :)
Thanks,
Heyi
On Wed, Mar 07, 2018 at 10:36:48AM +0100, Laszlo Ersek wrote:
> Hello Heyi,
>
> On 03/07/18 07:55, Heyi Guo wrote:
> > From: Jason Zhang
> >
> > Timer is always working on Hisilicon D0x, even system enters WF
On Wed, Mar 07, 2018 at 04:10:23PM +, Ard Biesheuvel wrote:
> On 7 March 2018 at 06:55, Heyi Guo wrote:
> > From: Chenhui Sun
> >
> > Add description of SBSA watchdogs to ACPI GTDT on D05.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Chenhui Sun
> > Sign
Thanks, I can try if ISB works. The issue was observed on Hisilicon D05
platform.
Regards,
Heyi
On Mon, Mar 12, 2018 at 09:46:41AM +, Marc Zyngier wrote:
> On 12/03/18 06:53, Heyi Guo wrote:
> > Resetting timer compare register has a side effect of clearing GIC
> > pending status, if timer
Hi Marc,
I just tested with an ISB and it also worked for our platform.
So is it acceptable to add an ISB after reloading timer compare value?
Regards,
Heyi
On Mon, Mar 12, 2018 at 06:26:43PM +0800, Guo Heyi wrote:
> Thanks, I can try if ISB works. The issue was observed on Hisilicon
On Mon, Mar 12, 2018 at 10:48:59AM +, Marc Zyngier wrote:
> On 12/03/18 10:38, Ard Biesheuvel wrote:
> > On 12 March 2018 at 10:38, Guo Heyi wrote:
> >> Hi Marc,
> >>
> >> I just tested with an ISB and it also worked for our platform.
> >>
Ard Biesheuvel wrote:
> >On 7 March 2018 at 04:30, Ni, Ruiyu wrote:
> >>On 3/6/2018 10:44 AM, Guo Heyi wrote:
> >>>
> >>>Hi Ray,
> >>>
> >>>Any comments for v5?
> >>
> >>
> >>Heyi,
> >>Some backward com
On Tue, Mar 13, 2018 at 09:33:33AM +, Marc Zyngier wrote:
> On 13/03/18 00:31, Heyi Guo wrote:
> > If timer interrupt is level sensitive, reloading timer compare
> > register has a side effect of clearing GIC pending status, so a "ISB"
> > is needed to make sure this instruction is executed bef
exe on Windows. It
success and produced a "Report.csv" with only a titel line. I guess this means
there is no error in the coding style, isn't it?
Please let me know if there is anything wrong with what I did.
Thanks and regards,
Heyi
On Wed, Mar 14, 2018 at 03:57:14PM +0800, Ni, Ruiyu
On Thu, Mar 15, 2018 at 01:26:04PM +0800, Ni, Ruiyu wrote:
> On 3/15/2018 12:00 PM, Heyi Guo wrote:
> >PCI address translation is necessary for some non-x86 platforms. On
> >such platforms, address value (denoted as "device address" or "address
> >in PCI view") set to PCI BAR registers in configura
On Thu, Mar 15, 2018 at 01:27:59PM +0800, Ni, Ruiyu wrote:
> On 3/15/2018 12:00 PM, Heyi Guo wrote:
> >v6:
> >- Patch 1, 2: implement 3 comments from Laszlo.
> >- Patch 4: implement 3 comments from Ray.
> >
> >Patch v5 inherits the code from RFC v4; we don't restart the version number
> >for
> >RF
this
issue.
Regards,
Heyi
On Wed, Mar 14, 2018 at 02:50:41PM +, Ard Biesheuvel wrote:
> On 14 March 2018 at 07:45, Marc Zyngier wrote:
> > On Wed, 14 Mar 2018 00:25:09 +,
> > Guo Heyi wrote:
> >>
> >> On Tue, Mar 13, 2018 at 09:33:33AM +, Marc Zyngie
Ping :)
On Wed, Mar 07, 2018 at 04:02:30PM +, Ard Biesheuvel wrote:
> On 7 March 2018 at 03:03, Heyi Guo wrote:
> > Since D0x platforms always have network enabled, we would like to
> > enable tftp command by default so that we can download something in
> > EFI Shell.
> >
> > Contributed-und
>
> Since it is now a dynamic command, is there any way of loading this
> dynamically (perhaps via DRIVER) where you feel the need for it?
>
> /
> Leif
>
> On Tue, Mar 20, 2018 at 03:54:46PM +0800, Guo Heyi wrote:
> > Ping :)
> >
> >
> &g
Hi folks,
The SetAttributes() interface of generic SerialDxe driver in
MdeModulePkg/Universal does not fully follow UEFI spec. The spec requires to use
default time out value when the input "Timeout" is 0, but the current
implementation will set timeout to 0 directly. It tries to pass "Timeout" t
+cc Maintainers of MdeModulePkg.
On Thu, Mar 22, 2018 at 07:39:42PM +0800, Guo Heyi wrote:
> Hi folks,
>
> The SetAttributes() interface of generic SerialDxe driver in
> MdeModulePkg/Universal does not fully follow UEFI spec. The spec requires to
> use
> default time out va
79 matches
Mail list logo
