Currently there is a duplicate GUID shared by two INFs.
This rolls the INF for the PrePiHobLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2381
Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The message "LibGetTime: RtcEpochSeconds non volatile variable was not
found - Using compilation time epoch." can be printed a very large
number of times, causing log files to become excessively large. This is
because the RtcEpochSeconds variable only gets set if LibSetTime is
called, for example by running 'time 12:00' in the UEFI Shell.
Avoid this by setting RtcEpochSeconds to BUILD_EPOCH (EpochSeconds)
after printing the message. It's set to a volatile variable so the
message will be displayed on future boots and not hidden.
Commit 44ae214591 reduced the verbosity of
the message to DEBUG_VERBOSE. Revert it back to DEBUG_INFO so it's more
prominent now that it doesn't get printed so frequently.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The DEBUG message for using compilation time epoch is appearing very
frequently on DEBUG firmware builds, for example during UEFI SCT runs.
Reduce verbosity to avoid the annoying repetitive message.
Signed-off-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The EfiGetVariable() is used in the entry of this module. So, the
variable services are required to be ready before they are used. This
patch adds the arch protocol gEfiVariableArchProtocolGuid to dependency
expression to guarantee that this module will be started once the
variable protocol is available.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Commit 55ee36b0c4
("EmbeddedPkg/RealTimeClockRuntimeDxe: Use helper functions from TimeBaseLib")
added a TimeBaseLib dependency to RealTimeClockRuntimeDxe, which now breaks
build of EmbeddedPkg.dsc.
Add a resolution for EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Nhi Pham <nhi@os.amperecomputing.com>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Use the correct type in the sizeof() expression to calculate the size
of the newly allocated EFI_HOB_MEMORY_POOL hob.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=3139
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
This adds two functions IsValidTimeZone() and IsValidDaylight() to check
the time zone and daylight value from EFI time. These functions are
retrieved from the RealTimeClockRuntimeDxe module as they reduce
duplicated code in RTC modules.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
There is no functional modification in this change.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
EfiTimeToEpoch() calls EfiGetEpochDays() internally, which (reasonably)
returns a UINTN. But then EfiTimeToEpoch() truncates the EfiGetEpochDays()
retval to UINT32 for no good reason, effectively restricting Time->Year
under 2106.
This truncation was pointed out with a valid warning (= build error) by
VS2019.
Allow EfiTimeToEpoch() to return / propagate a UINTN value.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201221113657.6779-3-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Addresses BZ https://bugzilla.tianocore.org/show_bug.cgi?id=2380 where
explicit casts are required for 64 to 32 bit assignment.
We can apply a straight cast for Time->Nanosecond since we already checked
for overflow.
On the other hand, we may have a frequency that is greater than UINT32_MAX
for Capabilities->Resolution. But using the frequency for the resolution
is the wrong approach anyway, since we can't actually vouch for the actual
resolution of the virtual library. Instead, play it safe by defaulting to
1 Hz, which is what a standard PC-AT CMOS RTC device would use.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The SEC_PER_MONTH and SEC_PER_YEAR macros are wrong: they both evaluate to
0 (of type "int"). They are also unused (they could never be used for
division, for example); so remove them. The macros were originally
introduced in commit 0f4386e775 ("ArmPlatformPkg/PL031RealTimeClockLib:
Implement PL031 RTC drive", 2011-06-11).
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Reported-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200904154541.23340-1-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
For the implementation which utilizes libfdt provided in EmbeddedPkg
however it uses strncmp function in the libfdt helper library,
libfdt_env.h should provide the macro implied with edk2 strncmp
implementation.
The example is RISC-V OpenSBI library. edk2 RISC-V port uses OpenSBI
library and incorporate with edk2 libfdt. edk2 libfdt_env.h provides
the necessary macros to build OpenSBI which uses fdt functions in edk2
environment. However, OpenSBI also has libfdt helper library that uses
strncmp function which is not defined in edk2 libfdt_env.h. This commit
addresses the build issue caused by missing strncmp macro in
libfdt_env.h.
Check below three commits for the corresponding changes on OpenSBI,
8e47649eff2845d2d2cf2cfd2fc904
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Message-Id: <20200806023421.25161-1-abner.chang@hpe.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
[lersek@redhat.com: remove stray newline between S-o-b and first Cc]
These can be used, for instance, to automate the population of an SMBIOS
Type 0 BIOS Release Date when building a UEFI firmware (which is how we
plan to use these macros for the Raspberry Pi platform).
These macros should work for any compiler that follows ISO/IEC 9899, but
we add a check for the compiler we have tested to be on the safe side.
Note that we decided against adding a #error or #warn for compilers that
haven't been validated, as we don't want to introduce breakage for people
who may already be using the header with something else than gcc, MSVC or
Clang. Instead, we expect those to send a patch that adds their compiler
to the list, once they have tested the macros there.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Commit dbd546a32d
("BaseTools: Add gcc flag to warn on void* pointer arithmetic")
does its work and triggers build errors in this library.
Update the affected code to build correctly again.
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Bob Feng<bob.c.feng@intel.com>
Reported-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The following command line:
build -b NOOPT -a IA32 -t VS2017 -p edk2\EmbeddedPkg\EmbeddedPkg.dsc
Generates the following error:
MmcDxe.lib(Diagnostics.obj) : error LNK2001:
unresolved external symbol __allshl
MmcDxe.lib(Diagnostics.obj) : error LNK2001:
unresolved external symbol __aullshr
MmcDxe.lib(MmcBlockIo.obj) : error LNK2001:
unresolved external symbol __allmul
These erros are due to the use of shift/multiply operations
on UINT64 variable on a IA32 architecture.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The bounce buffering code in NonCoherentDmaLib copies data into the
bounce buffer using CopyMem(), but passes Map->HostAddress as the
source of the copy before it has been assigned its correct value.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Moved BlockCount calculation below BufferSize Validation checks.
First Ensure Buffersize is Not Zero and multiple of Media BlockSize.
then calculate BlockCount and perform Block checks.
Corrected BlockCount calculation, as BufferSize is multiple of BlockSize,
So adding (BlockSize-1) bytes to BufferSize and
then divide by BlockSize will have no impact on BlockCount.
Reading Large Images from MMC causes errors.
As per SD Host Controller Spec version 4.20,
Restriction of 16-bit Block Count transfer is 65535.
Max block transfer limit in single cmd is 65535 blocks.
Added Max Block check that can be processed is 0xFFFF.
then Update BlockCount on the basis of MaxBlock.
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
Reviewed-by: "Loh, Tien Hock" <tien.hock.loh@intel.com>
Some driver were recently moved to edk2-platforms, but the DSC file
in EmbeddedPkg still refers to them. Drop these references.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The ISP 1716 USB host controller driver does not implement the UEFI
driver model, and is not a suitable example for new drivers to be
based on. Also, it is currently only used on a limited set of ARM
development platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The SiI3132 SATA controller driver does not implement the UEFI driver
model, and is not a suitable example for new drivers to be based on.
Also, it is currently only used on a limited set of ARM development
platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The Lan9118 network controller driver does not implement the UEFI driver
model, and is not a suitable example for new drivers to be based on.
Also, it is currently only used on a limited set of ARM development
platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The Lan91x network controller driver does not implement the UEFI driver
model, and is not a suitable example for new drivers to be based on.
Also, it is currently only used on a limited set of ARM development
platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The Synopsys DesignWare eMMC host controller driver does not implement
that SD/MMC host controller protocol that the UEFI spec defines, but an
obsolete EDK2-specific one that predates it. It also does not implement
the UEFI driver model.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
In EDK2, identifiers carrying the EFI prefix are reserved for ones
that are defined in the UEFI or PI specifications.
Since the MMC host protocol defined in EmbeddedPkg is not the one that
the UEFI spec defines, and given the confusion around this, let's rename
it to from gEfiMmcHostProtocolGuid to gEmbeddedMmcHostProtocolGuid.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
ACPI 6.3 added a 16-bit SPE overflow Interrupt field, replacing
2 of the 3 reserved bytes that are defined at the end of the
GICC structure for 6.0.
Add a new macro to initialise the new field.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
ASSERT in SetTime_Conf Consistency Test.
SCT Test expect return as Invalid Parameter.
So removed ASSERT().
While at it, check that the NanoSecond field is within the range given
by the UEFI specification.
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Implement a version of the EDK2 IoMmu protocol that is a simple wrapper
around DmaLib. This is intended to be used to wrap NonCoherentDmaLib so
that the generic PCI infrastructure can be used to implement support for
non cache-coherent DMA.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Tested-by: Pete Batard <pete@akeo.ie>
Implement support for driving peripherals with limited DMA ranges to
NonCoherentDmaLib, by adding a device address limit, and taking it,
along with the device offset, into account when allocating or mapping
DMA buffers.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Pete Batard <pete@akeo.ie>
Acked-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Add a PCD to govern whether to use DT or ACPI in case the
variable governing this is not found or is not valid.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The 3rd and 4th parameters of the CloseProtocol() call are wrong.
Given that we're not dissociating a child controller from a parent
controller (= closing a BY_CHILD_CONTROLLER open), but closing a BY_DRIVER
open, the 4th parameter (ControllerHandle) should equal the 1st parameter
(Handle).
It's unclear why this code hasn't crashed before.
Note that the patch doesn't fix the underlying driver model bug. I don't
understand what the loop in MmcDriverBindingStop() attempts to do. Is this
driver supposed to be a bus driver? It seems to create new handles, and to
append device path nodes. But it doesn't set up proper parent/child
protocol opens, and it doesn't close them.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
- The 2nd parameter of EFI_SERVICE_BINDING_CREATE_CHILD is:
IN OUT EFI_HANDLE *ChildHandle
- The 2nd parameter of EFI_SERVICE_BINDING_DESTROY_CHILD is:
IN EFI_HANDLE ChildHandle
Fix the DestroyChild() call in TcpFastbootTransportStop().
This is an actual bugfix; I don't know why the current code doesn't crash.
Perhaps the function is never reached in practice? (It could be tied to an
error path.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This patch is unrelated to the rest of the series; it just makes sure that
"EmbeddedPkg/EmbeddedPkg.dsc" builds for all platforms advertised in
SUPPORTED_ARCHITECTURES (in particular, X64).
No functional changes.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
This file contained what looked like windows 1250 encoded single
quotation marks. Convert them to regular 's. Rework the file to
markdown format and and rename it Readme.md while we're at it.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
While looking at encoding and line ending errors, I found this file
in fact simply points to a sourceforge page which no longer exists.
Since there is nothing more to say than "this is an import of
libfdt", let's just delete it.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.
This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in EmbeddedPkg which don't have the policy to defer the
execution of the image.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
The BaseTools build feature introduced for TianoCore#1804 / in commit
1fa6699e6c ("BaseTools: Add a checking for Sources section in INF file",
2019-06-10) logs some (non-fatal) warnings about unlisted internal header
files. List those files explicitly.
Note: header files are added in lexicographical order only if the
underlying INF file already keeps the [Sources] and [LibraryClasses]
sections in lexicographical order. Otherwise, header files are added in
rough "logical" order.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
EfiTimeToEpoch currently returns a UINTN.
Also, some internal calculations was using UINTN for fixed-width.
Both of these lead to warnings/errors with VS2017.
Replace with appropriate fixed-size types.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=997
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
The status code reporting functionality in PrePiLib is never invoked
so let's just remove it.
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1720
This commit will remove the dependency on IntelFramework[Module]Pkg from
the PrePiLib.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1720
This commit will update the package DSC file to consume the
ReportStatusCodeLib (DXE phase instance) in MdeModulePkg, instead of using
the one in IntelFrameworkModulePkg.
Please note that, the 2 ReportStatusCodeLib are almost identical. Thus,
there is no functional impact for this commit.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Latest change allowed to add dependency on NvVarStoreFormattedLib
for the DXE_DRIVER modules. Although effectively it is hooked
using the 'NULL' class, extend the LIBRARY_CLASS with according
type for consistency sake.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Some modules (such as FaultTolerantWriteDxe) use the FlashNvStorage
PCDs (PcdFlashNvStorageFtw*). In case the flash contents are not
mapped in memory, the module loading order of the FVB driver
may become important.
To handle above, this patch allows to hook the dependency of
desired DXE_DRIVER type module in the .DSC file via
NvVarStoreFormattedLib NULL resolution.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Matthew Carlson
Rebecca Cran
Samer El-Haj-Mahmoud
Nhi Pham
Leif Lindholm
Ard Biesheuvel
Laszlo Ersek
Pete Batard
Abner Chang
Michael D Kinney
Pierre Gondois
Gaurav Jain
Antoine Coeur
Philippe Mathieu-Daudé
Ard Biesheuvel
Ashish Singhal
Leif Lindholm
Dandan Bi
Liming Gao
Hao A Wu
Marcin Wojtas