Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

2019-04-02 Thread Ryszard Knop
On Tue, 2019-04-02 at 13:45 +0200, Laszlo Ersek wrote:
> On 04/02/19 13:29, Ryszard Knop wrote:
> > On Tue, 2019-04-02 at 10:12 +0100, Leif Lindholm wrote:
> > > Hi Laszlo,
> > > 
> > > On Tue, Apr 02, 2019 at 10:49:16AM +0200, Laszlo Ersek wrote:
> > > > On 04/02/19 07:38, Bi, Dandan wrote:
> > > > > Hi All,
> > > > > 
> > > > > ShellBinPkg is the remaining binary package in Edk2 repo.  We
> > > > > plan
> > > > > to delete ShellBinPkg from edk2/master, and keep source
> > > > > ShellPkg
> > > > > only in edk2 repo.
> > > > > Before the deletion, I will update the existing consumers in
> > > > > Edk2
> > > > > and Edk2Platforms to use ShellPkg directly.
> > > > > 
> > > > > If you have any concern please raise here before mid-April .
> > > > > If
> > > > > there is no concern, I will create patches for this task
> > > > > after
> > > > > mid-April.
> > > > > 
> > > > > Bugzilla for this task:
> > > > > https://bugzilla.tianocore.org/show_bug.cgi?id=1675
> > > > 
> > > > (adding a few CC's)
> > > > 
> > > > I think we should not remove ShellBinPkg without a replacement
> > > > *somehwere*.
> > > > 
> > > > A shell binary that is built from a validated edk2 tree, with a
> > > > set
> > > > of
> > > > library resolutions and PCD settings that are known to keep
> > > > platform
> > > > dependencies *out* of the shell binary, is extremely useful.
> > > 
> > > Agreed. However, I am not sure that accurately describes what we
> > > have
> > > today.
> > > 
> > > > IIRC, Andrew suggested earlier that we should treat the shell
> > > > even
> > > > as an
> > > > "OS", with better compatibility standards than we currently
> > > > maintain.
> > > > 
> > > > I think we should only remove ShellBinPkg if we permanently
> > > > offer a
> > > > separate download location instead, and we rebuild the shell
> > > > binary
> > > > from
> > > > "ShellPkg/ShellPkg.dsc" at every stable tag.
> > > 
> > > I think this sounds like an exellent improvement. When I saw the
> > > patch, I did immediately think maybe I should start including
> > > them in
> > > my Linaro releases. But if we could automate a build of binaries
> > > for
> > > all supported architectures, and have a place to publish them,
> > > that
> > > would be much better.
> > 
> > One place to put them might be next to the stable releases on
> > GitHub.
> > Sources are automatically packaged there, binaries can also be
> > uploaded, also automatically via CI. (Maybe it could also be used
> > to
> > keep stable OVMF images? Would be nice for quick testing for people
> > not
> > involved in UEFI development and not having these binaries
> > available in
> > their OS repos, or having issues with 3rd party builds.)
> 
> OVMF and ArmVirtQemu binaries are being bundled with upstream QEMU.
> The
> series should be merged into QEMU 4.1.

Right, but for people stuck on older QEMU versions it'd be useful to
find everything conveniently in one place when googling "OVMF". And
there are quite a few of these versions in the wild: 
https://repology.org/project/qemu/versions

> The plan is to refresh the firmware binaries for each edk2 stable
> tag.
> 
> (It's also possible that users could benefit from synching QEMU and
> edk2
> releases to an extent, similarly to how SeaBIOS and QEMU tend to be
> in
> sync. (IIRC SeaBIOS tends to cut a new release shortly before QEMU,
> so
> that QEMU can pick up the most recent release while it's fresh.)
> Anyway
> this sub-topic is for the future.)
> 
> Thanks
> Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [edk2-announce] Groups.io Transition

2019-04-02 Thread Ryszard Knop
Hi Stephano,
On https://edk2.groups.io/ the default group opened right away is
/g/devel, which is fine, but there isn't any indication of other groups
being available. It'd be useful to add links to other groups in the
description, for people not having your introductory mail linking other
groups available.
Thanks, Richard

On Thu, 2019-03-21 at 15:24 -0700, stephano wrote:
> First off, I'd like to thank Laszlo for his help in confirming the 
> functionality of the Groups.io mailing list. I could not have done
> this 
> without him. Groups.io seems to mimic our current list almost 100%, 
> certainly enough to make it viable. Also, it will allow such
> exciting 
> features as "email attachments", "email whitelisting", calendars,
> file 
> storage, and polls.
> 
> edk2-devel transition
> ---
> I am currently working with 01.org to archive our current mbox from 
> edk2-devel and move it over to Groups.io. Once this is complete we
> will 
> officially use that as our development mailing list.
> 
> 01.org and I are currently working out a date for the transition. I
> will 
> send out an email 2 weeks before the switch, again 1 week before the 
> switch, and 24 hours before we "go dark" on 01.org. Please update
> your 
> scripts / documents accordingly.
> 
> edk2-bugs transition
> ---
> Once we have been using groups.io for development emails for a few 
> weeks, I'll transition edk2-bugs over as well. I'd rather not do both
> at 
> the same time. Also, I want to give us a chance to collectively
> agree 
> that Groups.io is a successful platform.
> 
> Using Groups.io as a Community
> ---
> There are three "groups" in our current setup: devel, bugs, and 
> announce. Please take some time to familiarize yourself with the
> platform:
> 
> https://edk2.groups.io
> 
> The "default group" is devel, and that is where we will have any
> polls, 
> calendar updates, and file uploads. I will be sending out a Design 
> Meeting announcement soon which will rely heavily on this platform.
> 
> As always, please feel free to contact me with any questions or
> comments.
> 
> Cheers,
> Stephano
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

2019-04-02 Thread Ryszard Knop
On Tue, 2019-04-02 at 10:12 +0100, Leif Lindholm wrote:
> Hi Laszlo,
> 
> On Tue, Apr 02, 2019 at 10:49:16AM +0200, Laszlo Ersek wrote:
> > On 04/02/19 07:38, Bi, Dandan wrote:
> > > Hi All,
> > > 
> > > ShellBinPkg is the remaining binary package in Edk2 repo.  We
> > > plan
> > > to delete ShellBinPkg from edk2/master, and keep source ShellPkg
> > > only in edk2 repo.
> > > Before the deletion, I will update the existing consumers in Edk2
> > > and Edk2Platforms to use ShellPkg directly.
> > > 
> > > If you have any concern please raise here before mid-April . If
> > > there is no concern, I will create patches for this task after
> > > mid-April.
> > > 
> > > Bugzilla for this task:
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=1675
> > 
> > (adding a few CC's)
> > 
> > I think we should not remove ShellBinPkg without a replacement
> > *somehwere*.
> > 
> > A shell binary that is built from a validated edk2 tree, with a set
> > of
> > library resolutions and PCD settings that are known to keep
> > platform
> > dependencies *out* of the shell binary, is extremely useful.
> 
> Agreed. However, I am not sure that accurately describes what we have
> today.
> 
> > IIRC, Andrew suggested earlier that we should treat the shell even
> > as an
> > "OS", with better compatibility standards than we currently
> > maintain.
> > 
> > I think we should only remove ShellBinPkg if we permanently offer a
> > separate download location instead, and we rebuild the shell binary
> > from
> > "ShellPkg/ShellPkg.dsc" at every stable tag.
> 
> I think this sounds like an exellent improvement. When I saw the
> patch, I did immediately think maybe I should start including them in
> my Linaro releases. But if we could automate a build of binaries for
> all supported architectures, and have a place to publish them, that
> would be much better.

One place to put them might be next to the stable releases on GitHub.
Sources are automatically packaged there, binaries can also be
uploaded, also automatically via CI. (Maybe it could also be used to
keep stable OVMF images? Would be nice for quick testing for people not
involved in UEFI development and not having these binaries available in
their OS repos, or having issues with 3rd party builds.)

> Best Regards,
> 
> Leif
> 
> > In that case, removing ShellBinPkg would indeed improve the edk2
> > tree,
> > in my opinion.
> > 
> > Thanks,
> > Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 00/19] IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC

2019-03-28 Thread Ryszard Knop
On Wed, 2019-03-27 at 16:32 +0100, Ard Biesheuvel wrote:
> On Tue, 29 Jan 2019 at 14:55, Ryszard Knop <
> ryszard.k...@linux.intel.com> wrote:
> > +Team
> > 
> 
> As it turns out, this driver is still broken for non-1:1 mapped DMA.
> 
> In particular, I am hitting a crash on
> 
>   E1000MemCopy (
> (UINT8 *) (UINTN) CpbReceive->BufferAddr,
> (UINT8 *) (UINTN) ReceiveDescriptor->buffer_addr,
> TempLen
>   );
> 
> (around line 676 in e1000.c), which uses the DMA address
> 'ReceiveDescriptor->buffer_addr' in a memory copy operation performed
> by the CPU. This causes a crash on systems where the DMA address is
> not also a valid CPU address.

Huh, this is new... I don't have access to any system behaving this
way, so I can't test this, but E1000.c -> E1000TxRxConfigure links
RxDesc->buffer_addr to the physical addresses, that descriptor is used
by the hardware to DMA data where needed, and we try to copy from that
same physical address later, while we should copy from unmapped
addresses instead.

This probably should be solved by having a separate array/something
with CurRxInd -> unmapped addresses, but I'll have to talk with my team
to solve this in a sensible way.

In the meantime, maybe you know if there's a way to simulate this
situation under QEMU or something?


> > On Tue, 2019-01-29 at 14:13 +0100, Ryszard Knop wrote:
> > > Hi Ard,
> > > 
> > > I've finally got some time to review and merge all of this. A bit
> > > problematic thing is that we internally have a separate tree that
> > > we
> > > need to merge those commits into, then generate the open source
> > > tree
> > > and related commits from that. This will result in somewhat
> > > broken
> > > history, so sorry about that in advance - we're still figuring
> > > out
> > > the
> > > proper way to handle multiple source trees on our end without
> > > messing
> > > it up. I'll push these changes to edk2-staging once we've got it
> > > all
> > > ready.
> > > 
> > > On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> > > > This series fixes the GigUndiDxe in the edk2-staging/Intel_UNDI
> > > > branch
> > > > at github.com/tianocore so it can be built with GCC on Linux
> > > > for
> > > > ARM
> > > > and AARCH64 (as well as X64)
> > > > 
> > > > Ard Biesheuvel (19):
> > > >   IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to supported
> > > > architectures
> > > >   IntelUndiPkg: remove EOF markers
> > > >   IntelUndiPkg/GigUndiDxe: consistently use lowercase for e1000
> > > > in
> > > > filenames
> > > >   IntelUndiPkg/GigUndiDxe: consistently use forward slashes as
> > > > path
> > > > separators
> > > >   IntelUndiPkg/GigUndiDxe: move BRAND_STRUCT declaration after
> > > > type
> > > > definition
> > > >   IntelUndiPkg/GigUndiDxe: use intermediate UINTN casts for
> > > > pointers
> > > >   IntelUndiPkg/GigUndiDxe: create GCC alternatives for MSFT
> > > > build
> > > > options
> > > >   IntelUndiPkg/GigUndiDxe: add missing VOID** cast
> > > >   IntelUndiPkg/GigUndiDxe: add missing UINT8* cast
> > > >   IntelUndiPkg/GigUndiDxe: add missing braces to GUID literals
> > > >   IntelUndiPkg/GigUndiDxe: fix incorrect use of CPP token
> > > > pasting
> > > >   IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to correct
> > > > pointer
> > > > type
> > > >   IntelUndiPkg/GigUndiDxe: don't take address of cast
> > > > expression
> > > >   IntelUndiPkg/GigUndiDxe: redefine UNREFERENCED_nPARAMETER
> > > > macros
> > > > for
> > > > GCC
> > > >   IntelUndiPkg/GigUndiDxe: remove forward declaration of non-
> > > > existent
> > > > function
> > > >   IntelUndiPkg/GigUndiDxe: fix incorrect indentation
> > > >   IntelUndiPkg/GigUndiDxe: move MSFT warning overrides to INF
> > > > file
> > > >   IntelUndiPkg/GigUndiDxe: add missing EFIAPI modifiers
> > > >   IntelUndiPkg/GigUndiDxe: remove or reorganize unused
> > > > variables
> > > > 
> > > >  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  |  6 ++-
> > > >  IntelUndiPkg/GigUndiDxe/AdapterInformation.h  |  1 -
> > > >  IntelUndiPkg/GigUndiDxe/Brand.c   |  1 -

Re: [edk2] F29 Build Issue.

2019-03-13 Thread Ryszard Knop
Hi,
GenVtf is removed from EDK2, since it's IPF specific and no longer
used. Commit 64ab2c82e8f61e881eb16849e1b188361b00c4a7 deleted it from the 
upstream tree, so if you don't need IPF support, you can just remove this tool.
Richard

On Wed, 2019-03-13 at 09:27 -0400, Andrew J. Hutton wrote:
> Unsure if this is a missing build dependency (since there doesn't
> appear 
> to be a check for this) am I missing a make dep or configure step 
> somewhere?
> 
> This is stock F29, following the website instructions; the make -C 
> BaseTools/Source/C results in the following errror:
> 
> make[1]: Entering directory 
> '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C/GenVtf'
> cc  -c -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror 
> -Wno-deprecated-declarations -nostdlib -c -g  -I .. -I
> ../Include/Common 
> -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I
> . 
> -I ../Include/X64/  GenVtf.c -o GenVtf.o
> GenVtf.c: In function ‘CreateFitTableAndInitialize’:
> GenVtf.c:1473:3: error: ‘strncpy’ output truncated before
> terminating 
> nul copying 8 bytes from a string of the same length 
> [-Werror=stringop-truncation]
> strncpy ((CHAR8 *) >CompAddress, FIT_SIGNATURE, 8); 
> // 
> "_FIT_ "
> ^~~
> cc1: all warnings being treated as errors
> make[1]: *** [../Makefiles/footer.makefile:27: GenVtf.o] Error 1
> make[1]: Leaving directory 
> '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C/GenVtf'
> make: *** [GNUmakefile:73: GenVtf] Error 2
> make: Leaving directory
> '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C'
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH] CryptoPkg: Fix various typos

2019-02-07 Thread Ryszard Knop
Hi Philippe, Antoine,

On Wed, 2019-02-06 at 23:30 +0100, Philippe Mathieu-Daudé wrote:
> Hi Antoine,
> 
> On 2/6/19 6:24 PM, Antoine Coeur wrote:
> > Fix various typos in CryptoPkg.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Coeur 
> > ---
> >  CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 2 +-
> >  CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c | 4 ++--
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c
> > b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c
> > index d63c23df09..540c5715cb 100644
> > --- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c
> > +++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c
> > @@ -142,7 +142,7 @@ IMPLEMENT_ASN1_FUNCTIONS (TS_TST_INFO)
> >@param[in]  Asn1Time Pointer to the ASN.1
> > GeneralizedTime to be converted.
> >@param[out] SigningTime  Return the corresponding EFI Time.
> >  
> > -  @retval  TRUE   The time convertion succeeds.
> > +  @retval  TRUE   The time conversion succeeds.
> 
> The typos are indeed fixed, so:
> Reviewed-by: Philippe Mathieu-Daude 
> 
> However reading this description makes me suspicious, I'd have
> written
> "The time convertion succeeded.", but I'm not native English speaker
> so
> I'll let someone with more insurance opinate.

I'm not a native speaker either, but I'd write "conversion" as well.
(Like revert -> reversion, subvert -> subversion, avert -> aversion,
and so on.)

> 
> Regards,
> 
> Phil.
> 
> >@retval  FALSE  Invalid parameters.
> >  
> >  **/
> > diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> > b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> > index 9510a4a383..929e3fcd1e 100644
> > --- a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> > +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c
> > @@ -84,14 +84,14 @@ QuickSortWorker (
> >  }
> >}
> >//
> > -  // Swap pivot to it's final position (NextSwapLocaiton)
> > +  // Swap pivot to it's final position (NextSwapLocation)
> >//
> >CopyMem (Buffer, Pivot, ElementSize);
> >CopyMem (Pivot, (UINT8 *)BufferToSort + (NextSwapLocation *
> > ElementSize), ElementSize);
> >CopyMem ((UINT8 *)BufferToSort + (NextSwapLocation *
> > ElementSize), Buffer, ElementSize);
> >  
> >//
> > -  // Now recurse on 2 paritial lists.  Neither of these will have
> > the 'pivot' element.
> > +  // Now recurse on 2 partial lists.  Neither of these will have
> > the 'pivot' element.
> >// IE list is sorted left half, pivot element, sorted right
> > half...
> >//
> >QuickSortWorker (
> > 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 10/20] IntelUndiPkg/XGigUndiDxe: drop StdLibC library class reference

2019-02-06 Thread Ryszard Knop
Mike,

As mentioned in previous mails, we can't change some of our code to
meet the coding standard. I've filled BZ #1516 with everything we need,
plus what CryptoPkg provides for reference.

Thanks, Richard.

On Wed, 2019-01-30 at 20:58 +, Kinney, Michael D wrote:
> Hi Richard,
> 
> It is possible to update C code to prevent the use of compiler
> intrinsic functions.  This is what we have done for EDK II modules
> that are built for both IA32 and X64.
> 
> The one exception is the use of OpenSSL.  We prefer to use that
> project "as is" as a git submodule, so modifying the OpenSSL
> sources to prevent use of intrinsic functions was not practical.
> The CryptoPkg has the minimum set of intrinsic functions required
> For OpenSSL to build.
> 
> We do recognize that this issue is difficult for developers to
> resolve because the techniques require generation of mixed C/asm
> output files to track down the C statements that are generating
> the intrinsic functions.
> 
> Similar to the ARM support for an intrinsic lib, it may be 
> reasonable to add a small intrinsic lib for IA32 and X64 that
> supports the intrinsic functions that are seen the most often.
> May  require an intrinsic lib for each supported tool chain.
> 
> This would be a new feature that would take some effort to 
> implement and validate.  Can you enter an Bugzilla for this
> feature and list the specific intrinsic functions needed for
> this driver?
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Ryszard Knop
> > [mailto:ryszard.k...@linux.intel.com]
> > Sent: Wednesday, January 30, 2019 9:27 AM
> > To: Ard Biesheuvel ; edk2-
> > de...@lists.01.org; Carsey, Jaben
> > 
> > Cc: Kacperski, Kamil ; Jin,
> > Eric ; Orlowski, Pawel
> > ; Kinney, Michael D
> > ; Hsiung, Harry L
> > 
> > Subject: Re: [edk2] [PATCH edk2-staging 10/20]
> > IntelUndiPkg/XGigUndiDxe: drop StdLibC library class
> > reference
> > 
> > That's actually not quite correct - we need this
> > package to build on
> > IA32. It's named rather unfortunately, since it's not
> > the EDK2 StdLibC,
> > but rather a package in this repository - see
> > IntelUndiPkg/LibC. It
> > contains the bare minimum of functionality required to
> > fix missing 64-
> > bit math/shifts on IA32 and missing memcpy/memset
> > intrinsics. We can't
> > prevent MSVC from yielding memcpy/memset either, so
> > this was the nasty
> > solution for build issues. You have included
> > CompilerIntrinsicsLib for
> > the same reason, too :)
> > 
> > I'm not aware of any X64/IA32 equivalent of your
> > CompilerIntrinsicsLib,
> > but I'd be happy to be proven wrong here. I'm off for
> > the rest of the
> > week - I'll continue with reviews and merging early
> > next week.
> > 
> > Thanks, Richard.
> > 
> > On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela
> > wrote:
> > > StdLibc should not be used in drivers (it has
> > dependencies on Shell
> > > protocols), but in fact, we don't appear to rely on
> > it in the first
> > > place, so just drop the reference.
> > > 
> > > Contributed-under: TianoCore Contribution Agreement
> > 1.1
> > > Signed-off-by: Ard Biesheuvel  > linaro.org>
> > > ---
> > >  IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf | 1 -
> > >  1 file changed, 1 deletion(-)
> > > 
> > > diff --git a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> > > b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> > > index beee8aa8134e..b5747565fbea 100644
> > > --- a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> > > +++ b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> > > @@ -132,7 +132,6 @@ GCC:*_*_*_CC_FLAGS = -DEFI32
> > >PrintLib
> > >UefiLib
> > >HiiLib
> > > -  StdLibC
> > > 
> > >  [LibraryClasses.X64]
> > > 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 10/20] IntelUndiPkg/XGigUndiDxe: drop StdLibC library class reference

2019-02-06 Thread Ryszard Knop
Andrew,

Unfortunately, not assigning something too large or using math
functions is not an option for us, as we share a significant amount of
code with Linux/FreeBSD drivers and maintainers of that code don't want
changes similar to the ones below (especially that, for all the other
drivers, intrinsics just work). Intrinsic lib for IA32 and others would
be very much preferred (and one that just works on any architecture, so
that we wouldn't have to add extra arch-specific LibraryClasses).

Thanks, Richard

On Wed, 2019-01-30 at 10:34 -0800, Andrew Fish wrote:
> > On Jan 30, 2019, at 9:26 AM, Ryszard Knop <
> > ryszard.k...@linux.intel.com> wrote:
> > 
> > That's actually not quite correct - we need this package to build
> > on
> > IA32. It's named rather unfortunately, since it's not the EDK2
> > StdLibC,
> > but rather a package in this repository - see IntelUndiPkg/LibC. It
> > contains the bare minimum of functionality required to fix missing
> > 64-
> > bit math/shifts on IA32 and missing memcpy/memset intrinsics. We
> > can't
> > prevent MSVC from yielding memcpy/memset either, so this was the
> > nasty
> > solution for build issues. You have included CompilerIntrinsicsLib
> > for
> > the same reason, too :)
> > 
> 
> Ryszard,
> 
> For IA32/X64 we avoid the compiler intrinsic libs via the coding
> standard. 
> 1) If you don't assign something too large at execution time with an
> = the compiler will not inline memcpy()/memset()
> 2) BaseLib.h has all the math functions that generate intrinsics that
> your code can call explicitly: 
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/BaseLib.h#L3533
> 
> UINT64 X=0x1;
> UINT64 Y=2;
> 
> So:
> Y = X*Y;
> should be:
> Y = MultU64x64 (X, Y);
> 
> When ARM got added much later and some versions of ARM did not even
> have a divide instruction we gave up on trying to add more functions
> into all the existing IA32 code, and add the intrinsic lib. 
> 
> If we are going to add an intrinsic lib for x86 then we should
> probably add it to the MdePkg and it needs to support MSVC and GCC
> (as far as I can tell clang should work with the GCC intrinsics). 
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> > I'm not aware of any X64/IA32 equivalent of your
> > CompilerIntrinsicsLib,
> > but I'd be happy to be proven wrong here. I'm off for the rest of
> > the
> > week - I'll continue with reviews and merging early next week.
> > 
> > Thanks, Richard.
> > 
> > On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> > > StdLibc should not be used in drivers (it has dependencies on
> > > Shell
> > > protocols), but in fact, we don't appear to rely on it in the
> > > first
> > > place, so just drop the reference.
> > > 
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Ard Biesheuvel 
> > > ---
> > > IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf | 1 -
> > > 1 file changed, 1 deletion(-)
> > > 
> > > diff --git a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> > > b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> > > index beee8aa8134e..b5747565fbea 100644
> > > --- a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> > > +++ b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> > > @@ -132,7 +132,6 @@ GCC:*_*_*_CC_FLAGS = -DEFI32
> > >   PrintLib
> > >   UefiLib
> > >   HiiLib
> > > -  StdLibC
> > > 
> > > [LibraryClasses.X64]
> > > 
> > 
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> 
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 10/20] IntelUndiPkg/XGigUndiDxe: drop StdLibC library class reference

2019-01-30 Thread Ryszard Knop
That's actually not quite correct - we need this package to build on
IA32. It's named rather unfortunately, since it's not the EDK2 StdLibC,
but rather a package in this repository - see IntelUndiPkg/LibC. It
contains the bare minimum of functionality required to fix missing 64-
bit math/shifts on IA32 and missing memcpy/memset intrinsics. We can't
prevent MSVC from yielding memcpy/memset either, so this was the nasty
solution for build issues. You have included CompilerIntrinsicsLib for
the same reason, too :)

I'm not aware of any X64/IA32 equivalent of your CompilerIntrinsicsLib,
but I'd be happy to be proven wrong here. I'm off for the rest of the
week - I'll continue with reviews and merging early next week.

Thanks, Richard.

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> StdLibc should not be used in drivers (it has dependencies on Shell
> protocols), but in fact, we don't appear to rely on it in the first
> place, so just drop the reference.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> index beee8aa8134e..b5747565fbea 100644
> --- a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> +++ b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> @@ -132,7 +132,6 @@ GCC:*_*_*_CC_FLAGS = -DEFI32
>PrintLib
>UefiLib
>HiiLib
> -  StdLibC
>  
>  [LibraryClasses.X64]
>

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 18/20] IntelUndiPkg/XGigUndiDxe: set MDEPKG_NDEBUG only for RELEASE builds

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> Only define the CPP macro MDEPKG_NDEBUG for the RELEASE target so
> that debug features are functional otherwise.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> index b5747565fbea..e3201fb9881f 100644
> --- a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> +++ b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> @@ -44,7 +44,8 @@ UNLOAD_IMAGE = UnloadXGigUndiDriver
>  
>  [BuildOptions.common]
>  
> -MSFT:*_*_*_CC_FLAGS = /FAcs /D MDEPKG_NDEBUG /D UNDI_10G /wd4244
> /wd4206 /wd4189
> +MSFT:*_*_*_CC_FLAGS = /FAcs /D UNDI_10G /wd4244 /wd4206 /wd4189
> +MSFT:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
>  GCC:*_*_*_CC_FLAGS = -DUNDI_10G
>  GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>  

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 17/20] IntelUndiPkg/XGigUndiDxe: drop unused variables

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> Drop some variables that are defined, assigned but never referenced.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/Decode.c | 3 ---
>  IntelUndiPkg/XGigUndiDxe/HiiInternalLib.c | 4 
>  IntelUndiPkg/XGigUndiDxe/Xgbe.c   | 2 --
>  3 files changed, 9 deletions(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/Decode.c
> b/IntelUndiPkg/XGigUndiDxe/Decode.c
> index 5f37ce254872..c8dc3f4eb659 100644
> --- a/IntelUndiPkg/XGigUndiDxe/Decode.c
> +++ b/IntelUndiPkg/XGigUndiDxe/Decode.c
> @@ -1454,14 +1454,11 @@ UndiStatus (
>)
>  {
>PXE_DB_GET_STATUS *  DbPtr;
> -  UINT16   i;
>UINT32   IntStatus;
>UINT16   NumEntries;
>struct ixgbe_legacy_rx_desc *RxPtr;
>bool LinkUp;
>  
> -  i = 0;
> -
>if (XgbeAdapter->DriverBusy) {
>
>  //DEBUGPRINT (CRITICAL, ("ERROR: UndiStatus called when driver
> busy\n"));
> diff --git a/IntelUndiPkg/XGigUndiDxe/HiiInternalLib.c
> b/IntelUndiPkg/XGigUndiDxe/HiiInternalLib.c
> index 2aacb63ca158..df5238a3b55a 100644
> --- a/IntelUndiPkg/XGigUndiDxe/HiiInternalLib.c
> +++ b/IntelUndiPkg/XGigUndiDxe/HiiInternalLib.c
> @@ -197,7 +197,6 @@ GetNextRequestElement (
>)
>  {
>EFI_STRING StringPtr;
> -  EFI_STRING TmpPtr;
>EFI_STATUS Status;
>UINTN  Length;
>UINT8 *TmpBuffer;
> @@ -226,9 +225,6 @@ GetNextRequestElement (
>  return NULL;
>}
>  
> -  // Back up the header of one 
> -  TmpPtr = StringPtr;
> -
>StringPtr += StrLen (L"OFFSET=");
>  
>// Get Offset
> diff --git a/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> b/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> index 6769f2dc72ab..b3dbbd2b1d08 100644
> --- a/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> +++ b/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> @@ -1399,12 +1399,10 @@ XgbeInitialize (
>XGBE_DRIVER_DATA *XgbeAdapter
>)
>  {
> -  UINT32 * TempBar;
>PXE_STATCODE PxeStatcode;
>EFI_STATUS   Status;
>  
>PxeStatcode = PXE_STATCODE_SUCCESS;
> -  TempBar = NULL;
>  
>ZeroMem (
>  (VOID *)(UINTN)XgbeAdapter->RxRing.UnmappedAddress,

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 16/20] IntelUndiPkg/XGigUndiDxe: add missing EFIAPI modifiers

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> When building for the X64 target using GCC, correct use of the
> EFIAPI modifiers is essential to ensure that the correct calling
> convention is used. So add the missing ones where appropriate.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/AdapterInformation.c | 3 +++
>  IntelUndiPkg/XGigUndiDxe/ComponentName.c  | 2 ++
>  IntelUndiPkg/XGigUndiDxe/ComponentName.h  | 1 +
>  IntelUndiPkg/XGigUndiDxe/DriverDiagnostics.c  | 1 +
>  IntelUndiPkg/XGigUndiDxe/DriverHealth.c   | 2 ++
>  IntelUndiPkg/XGigUndiDxe/StartStop.c  | 2 ++
>  6 files changed, 11 insertions(+)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/AdapterInformation.c
> b/IntelUndiPkg/XGigUndiDxe/AdapterInformation.c
> index 26556e284381..b25ed7c4f022 100644
> --- a/IntelUndiPkg/XGigUndiDxe/AdapterInformation.c
> +++ b/IntelUndiPkg/XGigUndiDxe/AdapterInformation.c
> @@ -123,6 +123,7 @@ GetIpv6SupportInformationBlock (
>  **/
>  STATIC
>  EFI_STATUS
> +EFIAPI
>  GetInformation (
>IN  EFI_ADAPTER_INFORMATION_PROTOCOL *This,
>IN  EFI_GUID *InformationType,
> @@ -188,6 +189,7 @@ GetInformation (
>  **/
>  STATIC
>  EFI_STATUS
> +EFIAPI
>  SetInformation (
>IN  EFI_ADAPTER_INFORMATION_PROTOCOL *This,
>IN  EFI_GUID *InformationType,
> @@ -234,6 +236,7 @@ SetInformation (
>  **/
>  STATIC
>  EFI_STATUS
> +EFIAPI
>  GetSupportedTypes (
>IN  EFI_ADAPTER_INFORMATION_PROTOCOL *This,
>OUT EFI_GUID **   InfoTypesBuffer,
> diff --git a/IntelUndiPkg/XGigUndiDxe/ComponentName.c
> b/IntelUndiPkg/XGigUndiDxe/ComponentName.c
> index 2972c28bda4e..eee59d7c14f4 100644
> --- a/IntelUndiPkg/XGigUndiDxe/ComponentName.c
> +++ b/IntelUndiPkg/XGigUndiDxe/ComponentName.c
> @@ -116,6 +116,7 @@ ComponentNameInitializeControllerName (
>  language specified by Language.
>  **/
>  EFI_STATUS
> +EFIAPI
>  ComponentNameGetDriverName (
>IN  EFI_COMPONENT_NAME_PROTOCOL *This,
>IN  CHAR8 *  Language,
> @@ -186,6 +187,7 @@ ComponentNameGetDriverName (
>  language specified by Language.
>  **/
>  EFI_STATUS
> +EFIAPI
>  ComponentNameGetControllerName (
>IN  EFI_COMPONENT_NAME_PROTOCOL
> *   This,
>IN  EFI_HANDLE  Co
> ntrollerHandle,
> diff --git a/IntelUndiPkg/XGigUndiDxe/ComponentName.h
> b/IntelUndiPkg/XGigUndiDxe/ComponentName.h
> index f63d58b8a18c..4f62e48379ed 100644
> --- a/IntelUndiPkg/XGigUndiDxe/ComponentName.h
> +++ b/IntelUndiPkg/XGigUndiDxe/ComponentName.h
> @@ -67,6 +67,7 @@ ComponentNameInitializeControllerName (
>  language specified by Language.
>  **/
>  EFI_STATUS
> +EFIAPI
>  ComponentNameGetDriverName (
>IN  EFI_COMPONENT_NAME_PROTOCOL *This,
>IN  CHAR8 *  Language,
> diff --git a/IntelUndiPkg/XGigUndiDxe/DriverDiagnostics.c
> b/IntelUndiPkg/XGigUndiDxe/DriverDiagnostics.c
> index 2f9c66771910..77b7a954698b 100644
> --- a/IntelUndiPkg/XGigUndiDxe/DriverDiagnostics.c
> +++ b/IntelUndiPkg/XGigUndiDxe/DriverDiagnostics.c
> @@ -370,6 +370,7 @@ XgbeUndiPhyLoopback (
>   ChildHandle did not pass
> the diagnostic.
>  **/
>  EFI_STATUS
> +EFIAPI
>  XgbeUndiDriverDiagnosticsRunDiagnostics (
>IN EFI_DRIVER_DIAGNOSTICS_PROTOCOL
> *   This,
>IN
> EFI_HANDLE  C
> ontrollerHandle,
> diff --git a/IntelUndiPkg/XGigUndiDxe/DriverHealth.c
> b/IntelUndiPkg/XGigUndiDxe/DriverHealth.c
> index df6cfdf8a123..4b173bc8d8a9 100644
> --- a/IntelUndiPkg/XGigUndiDxe/DriverHealth.c
> +++ b/IntelUndiPkg/XGigUndiDxe/DriverHealth.c
> @@ -45,6 +45,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
> @retval  !EFI_SUCCESS  Failure to retrieve health status
>  **/
>  EFI_STATUS
> +EFIAPI
>  GetHealthStatus (
>IN  EFI_DRIVER_HEALTH_PROTOCOL * This,
>IN  EFI_HANDLE   ControllerHandle, OPTIONAL
> @@ -145,6 +146,7 @@ GetHealthStatus (
> @retval   EFI_UNSUPPORTED   This function is unsupported
>  **/
>  EFI_STATUS
> +EFIAPI
>  Repair (
>IN  EFI_DRIVER_HEALTH_PROTOCOL*This,
>IN  EFI_HANDLEControllerHandle,
> diff --git a/IntelUndiPkg/XGigUndiDxe/StartStop.c
> b/I

Re: [edk2] [PATCH edk2-staging 15/20] IntelUndiPkg/XGigUndiDxe: use intermediate UINTN casts for pointers

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> Use intermediate (UINTN) casts when casting pointers to UINT64.
> This is needed to be able to build this code for 32-bit architectures
> such as ARM or IA32.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/Dma.c   | 8 
>  IntelUndiPkg/XGigUndiDxe/DriverDiagnostics.c | 4 ++--
>  IntelUndiPkg/XGigUndiDxe/Init.c  | 6 +++---
>  IntelUndiPkg/XGigUndiDxe/Xgbe.c  | 8 
>  IntelUndiPkg/XGigUndiDxe/Xgbe.h  | 4 ++--
>  5 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/Dma.c
> b/IntelUndiPkg/XGigUndiDxe/Dma.c
> index c8588df96ef5..79a5cefe9f41 100644
> --- a/IntelUndiPkg/XGigUndiDxe/Dma.c
> +++ b/IntelUndiPkg/XGigUndiDxe/Dma.c
> @@ -127,7 +127,7 @@ FREE_BUF_ON_ERROR:
>PciIo->FreeBuffer (
> PciIo,
> BytesToPages (DmaMapping->Size),
> -   (VOID *) DmaMapping->UnmappedAddress
> +   (VOID *)(UINTN)DmaMapping->UnmappedAddress
> );
>DmaMapping->Size = 0;
>DmaMapping->UnmappedAddress = 0;
> @@ -173,7 +173,7 @@ UndiDmaFreeCommonBuffer (
>PciIo->FreeBuffer (
> PciIo,
> BytesToPages (DmaMapping->Size),
> -   (VOID *) DmaMapping->UnmappedAddress
> +   (VOID *)(UINTN)DmaMapping->UnmappedAddress
> );
>  
>DmaMapping->UnmappedAddress = 0;
> @@ -209,7 +209,7 @@ UndiDmaMapCommonBuffer (
>return PciIo->Map (
>PciIo,
>EfiPciIoOperationBusMasterCommonBuffer,
> -  (VOID *) DmaMapping->UnmappedAddress,
> +  (VOID *)(UINTN)DmaMapping->UnmappedAddress,
>>Size,
>>PhysicalAddress,
>>Mapping
> @@ -243,7 +243,7 @@ UndiDmaMapMemoryRead (
>return PciIo->Map (
>PciIo,
>EfiPciIoOperationBusMasterRead,
> -  (VOID *) DmaMapping->UnmappedAddress,
> +  (VOID *)(UINTN)DmaMapping->UnmappedAddress,
>>Size,
>>PhysicalAddress,
>>Mapping
> diff --git a/IntelUndiPkg/XGigUndiDxe/DriverDiagnostics.c
> b/IntelUndiPkg/XGigUndiDxe/DriverDiagnostics.c
> index 66dc67a5400e..2f9c66771910 100644
> --- a/IntelUndiPkg/XGigUndiDxe/DriverDiagnostics.c
> +++ b/IntelUndiPkg/XGigUndiDxe/DriverDiagnostics.c
> @@ -119,11 +119,11 @@ XgbeUndiRunPhyLoopback (
>DEBUGPRINT (DIAG, ("CpbReceive.BufferAddr allocated at %x\n",
> (UINTN) CpbReceive.BufferAddr));
>  
>while (j < PHY_LOOPBACK_ITERATIONS) {
> -ZeroMem ((VOID *) CpbReceive.BufferAddr, RX_BUFFER_SIZE);
> +ZeroMem ((VOID *)(UINTN)CpbReceive.BufferAddr, RX_BUFFER_SIZE);
>  
>  Status = XgbeTransmit (
> XgbeAdapter,
> -   (UINT64) ,
> +   (UINT64)(UINTN),
> PXE_OPFLAGS_TRANSMIT_WHOLE
>   );
>  
> diff --git a/IntelUndiPkg/XGigUndiDxe/Init.c
> b/IntelUndiPkg/XGigUndiDxe/Init.c
> index 03e3942a1944..c112db667148 100644
> --- a/IntelUndiPkg/XGigUndiDxe/Init.c
> +++ b/IntelUndiPkg/XGigUndiDxe/Init.c
> @@ -260,7 +260,7 @@ InitUndiPxeStructInit (
> PXE_ROMID_IMP_TX_COMPLETE_INT_SUPPORTED |
> PXE_ROMID_IMP_PACKET_RX_INT_SUPPORTED;
>  
> -  PxePtr->EntryPoint= (UINT64) UndiApiEntry;
> +  PxePtr->EntryPoint= (UINT64)(UINTN)UndiApiEntry;
>PxePtr->MinorVer  = PXE_ROMID_MINORVER_31;
>  
>PxePtr->reserved2[0]  = 0;
> @@ -1099,7 +1099,7 @@ InitUndiCallbackFunctions (
>NicInfo->MapMem  = (VOID *) 0;
>NicInfo->UnMapMem= (VOID *) 0;
>NicInfo->SyncMem = (VOID *) 0;
> -  NicInfo->UniqueId   = (UINT64) NicInfo;
> +  NicInfo->UniqueId   = (UINT64)(UINTN)NicInfo;
>NicInfo->VersionFlag = 0x31;
>  }
>  
> @@ -1284,7 +1284,7 @@ InitNiiProtocol (
>EFI_STATUS Status;
>  
>  
> -  NiiProtocol31->Id= (UINT64) (mIxgbePxe31);
> +  NiiProtocol31->Id= (UINT64)(UINTN)(mIxgbePxe31);
>  
>// IFcnt should be equal to the total number of physical ports - 1
>NiiProtocol31->IfNum = mIxgbePxe31->IFcnt;
> diff --git a/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> b/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> index 003c3b9065ec..6769f2dc72ab 100644
> --- a/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> +++ b/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> @@ -

Re: [edk2] [PATCH edk2-staging 14/20] IntelUndiPkg/XGigUndiDxe: redefine UNREFERENCED_nPARAMETER macros for GCC

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> Use (VOID) casts to silence unreferenced parameter warnings on GCC.
> The
> existing macros generate 'statement with no effect' warnings instead,
> which does not really help.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/ixgbe_type.h | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/ixgbe_type.h
> b/IntelUndiPkg/XGigUndiDxe/ixgbe_type.h
> index e3bb1a8a313e..f67bfbfc2a9f 100644
> --- a/IntelUndiPkg/XGigUndiDxe/ixgbe_type.h
> +++ b/IntelUndiPkg/XGigUndiDxe/ixgbe_type.h
> @@ -4411,11 +4411,19 @@ struct ixgbe_hw {
>  #define IXGBE_NOT_IMPLEMENTED0x7FFF
>  
>  #ifndef UNREFERENCED_XPARAMETER
> +#ifdef _MSC_VER
>  #define UNREFERENCED_XPARAMETER
>  #define UNREFERENCED_1PARAMETER(_p) (_p);
>  #define UNREFERENCED_2PARAMETER(_p, _q) (_p); (_q);
>  #define UNREFERENCED_3PARAMETER(_p, _q, _r) (_p); (_q); (_r);
>  #define UNREFERENCED_4PARAMETER(_p, _q, _r, _s) (_p); (_q); (_r);
> (_s);
> +#else
> +#define UNREFERENCED_1PARAMETER(_p) (VOID)(_p)
> +#define UNREFERENCED_2PARAMETER(_p, _q) (VOID)(_p); (VOID)(_q);
> +#define UNREFERENCED_3PARAMETER(_p, _q, _r) (VOID)(_p); (VOID)(_q);
> (VOID)(_r);
> +#define UNREFERENCED_4PARAMETER(_p, _q, _r, _s) (VOID)(_p);
> (VOID)(_q); (VOID)(_r); (VOID)(_s);
> +#define UNREFERENCED_5PARAMETER(_p, _q, _r, _s, _t) (VOID)(_p);
> (VOID)(_q); (VOID)(_r); (VOID)(_s); (VOID)(_t);
> +#endif
>  #endif
>  #define IXGBE_FUSES0_GROUP(_i)   (0x11158 + ((_i) * 4))
>  #define IXGBE_FUSES0_300MHZ  (1 << 5)

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 11/20] IntelUndiPkg/XGigUndiDxe: cast XgbeMemCopy () args to correct pointer type

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> XgbeMemCopy () takes UINT8 pointers not INT8 pointers, so cast the
> arguments to the correct type.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/Xgbe.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> b/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> index 9e3ee862fb4e..0c823efe8963 100644
> --- a/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> +++ b/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> @@ -542,8 +542,8 @@ XgbeReceive (
>  
>// Copy the packet from our list to the EFI buffer.
>XgbeMemCopy (
> -(INT8 *) (UINTN) CpbReceive->BufferAddr,
> -(INT8 *) (UINTN) ReceiveDescriptor->buffer_addr,
> +(UINT8 *) (UINTN) CpbReceive->BufferAddr,
> +(UINT8 *) (UINTN) ReceiveDescriptor->buffer_addr,
>  TempLen
>);
>  

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 12/20] IntelUndiPkg/XGigUndiDxe: don't take address of cast expression

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> Taking the address of a cast expression is not permitted in C.
> Instead,
> take the address of the variable, and cast the pointer to the desired
> pointer type.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/Xgbe.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> b/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> index 0c823efe8963..003c3b9065ec 100644
> --- a/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> +++ b/IntelUndiPkg/XGigUndiDxe/Xgbe.c
> @@ -1264,7 +1264,7 @@ XgbeTxRxConfigure (
>IXGBE_WRITE_REG (>Hw, IXGBE_RDBAL (0), (UINT32)
> (UINTN) (XgbeAdapter->RxRing.PhysicalAddress));
>  
>MemAddr = (UINT64) (UINTN) XgbeAdapter->RxRing.PhysicalAddress;
> -  MemPtr  = &((UINT32) MemAddr);
> +  MemPtr  = (UINT32 *) 
>MemPtr++;
>IXGBE_WRITE_REG (>Hw, IXGBE_RDBAH (0), *MemPtr);
>DEBUGPRINT (XGBE, ("Rdbal0 %X\n", (UINT32) IXGBE_READ_REG
> (>Hw, IXGBE_RDBAL (0;
> @@ -1337,7 +1337,7 @@ XgbeTxRxConfigure (
>XgbeAdapter->XmitDoneHead = 0;  // the last cleaned buffer
>IXGBE_WRITE_REG (>Hw, IXGBE_TDBAL (0), (UINT32)
> (XgbeAdapter->TxRing.PhysicalAddress));
>MemAddr = (UINT64) XgbeAdapter->TxRing.PhysicalAddress;
> -  MemPtr  = &((UINT32) MemAddr);
> +  MemPtr  = (UINT32 *) 
>MemPtr++;
>IXGBE_WRITE_REG (>Hw, IXGBE_TDBAH (0), *MemPtr);
>DEBUGPRINT (XGBE, ("TdBah0 %X\n", *MemPtr));

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 07/20] IntelUndiPkg/XGigUndiDxe: drop definition of gImageHandle

2019-01-30 Thread Ryszard Knop
Ah, thanks!

On Wed, 2019-01-30 at 17:06 +0100, Ard Biesheuvel wrote:
> On Wed, 30 Jan 2019 at 17:05, Ryszard Knop <
> ryszard.k...@linux.intel.com> wrote:
> > Hmm, is there a list/something I can generate to see which globals
> > build tools emit? There are some more variables I'd happily get rid
> > of, eg if I could drop gSystemTable and others.
> > 
> 
> You can look at the contents of the various AutoGen.h files in the
> Build/ folder
> 
> 
> > Reviewed-by: Ryszard Knop 
> > 
> > On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> > > Remove duplicate definition of gImageHandle, which is emitted by
> > > the build tools as well.
> > > 
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Ard Biesheuvel 
> > > ---
> > >  IntelUndiPkg/XGigUndiDxe/Init.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > > 
> > > diff --git a/IntelUndiPkg/XGigUndiDxe/Init.c
> > > b/IntelUndiPkg/XGigUndiDxe/Init.c
> > > index 84e06ea071c5..03e3942a1944 100644
> > > --- a/IntelUndiPkg/XGigUndiDxe/Init.c
> > > +++ b/IntelUndiPkg/XGigUndiDxe/Init.c
> > > @@ -47,7 +47,6 @@ UINT16 mActiveChildren= 0;
> > >  EFI_EVENT  gEventNotifyExitBs;
> > >  EFI_EVENT  gEventNotifyVirtual;
> > > 
> > > -EFI_HANDLEgImageHandle;
> > >  EFI_SYSTEM_TABLE *gSystemTable;
> > > 
> > >  EFI_GUID gEfiNiiPointerGuid = EFI_NII_POINTER_PROTOCOL_GUID;
> > > @@ -502,7 +501,6 @@ InitializeXGigUndiDriver (
> > >  {
> > >EFI_STATUS Status;
> > > 
> > > -  gImageHandle  = ImageHandle;
> > >gSystemTable  = SystemTable;
> > > 
> > >Status = EfiLibInstallDriverBinding (ImageHandle, SystemTable,
> > > , ImageHandle);

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 09/20] IntelUndiPkg/XGigUndiDxe: fix incorrect use of CPP token pasting

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> The ## CPP token pasting operator is used to paste *tokens*, which
> is not the same thing as pasting arbitrary macro arguments. Since a
> token cannot contain . or ) characters in the first place, using
> the ## operator here is wrong and unnecessary, so just remove it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/NVDataStruc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/NVDataStruc.h
> b/IntelUndiPkg/XGigUndiDxe/NVDataStruc.h
> index 63dd841277ab..c78d26da7869 100644
> --- a/IntelUndiPkg/XGigUndiDxe/NVDataStruc.h
> +++ b/IntelUndiPkg/XGigUndiDxe/NVDataStruc.h
> @@ -113,7 +113,7 @@ typedef struct {
>  
> @return   Width of given field is returned
>  **/
> -#define UNDI_CONFIG_WIDTH(Field) sizeof (UndiPrivateData-
> >Configuration. ## Field ## )
> +#define UNDI_CONFIG_WIDTH(Field) sizeof (UndiPrivateData-
> >Configuration.Field)
>  
>  // General parameters
>  #define QUESTION_ID_EFI_DRIVER_VER  0x11
> 00

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 08/20] IntelUndiPkg/XGigUndiDxe: add missing braces to GUID literals

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> The Data4 member of the GUID/EFI_GUID struct type is an array of
> UINT8, so literals require two sets of { } braces. Add them where
> missing.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/NVDataStruc.h | 4 ++--
>  IntelUndiPkg/XGigUndiDxe/StartStop.h   | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/NVDataStruc.h
> b/IntelUndiPkg/XGigUndiDxe/NVDataStruc.h
> index e5e669681b07..63dd841277ab 100644
> --- a/IntelUndiPkg/XGigUndiDxe/NVDataStruc.h
> +++ b/IntelUndiPkg/XGigUndiDxe/NVDataStruc.h
> @@ -34,12 +34,12 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
>  #define XGBE_HII_FORM_GUID \
>{ \
> -0x25fd9f0b, 0xa3ef, 0x4788, 0xa4, 0x0c, 0x81, 0x84, 0x9d, 0x17,
> 0x8a, 0x6c \
> +0x25fd9f0b, 0xa3ef, 0x4788, { 0xa4, 0x0c, 0x81, 0x84, 0x9d,
> 0x17, 0x8a, 0x6c } \
>}
>  
>  #define XGBE_HII_DATA_GUID \
>{ \
> -0xe2c85968, 0x6906, 0x4b27, 0x9d, 0x09, 0x33, 0x43, 0xaf, 0x06,
> 0x46, 0x76 \
> +0xe2c85968, 0x6906, 0x4b27, { 0x9d, 0x09, 0x33, 0x43, 0xaf,
> 0x06, 0x46, 0x76 } \
>}
>  
>  
> diff --git a/IntelUndiPkg/XGigUndiDxe/StartStop.h
> b/IntelUndiPkg/XGigUndiDxe/StartStop.h
> index 03ad3dc9cecc..5dfc45c7de6a 100644
> --- a/IntelUndiPkg/XGigUndiDxe/StartStop.h
> +++ b/IntelUndiPkg/XGigUndiDxe/StartStop.h
> @@ -32,8 +32,8 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  #include "Xgbe.h"
>  
>  #define EFI_DRIVER_STOP_PROTOCOL_GUID \
> -  { 0x34d59603, 0x1428, 0x4429, 0xa4, 0x14, 0xe6, 0xb3, \
> -0xb5, 0xfd, 0x7d, 0xc1 }
> +  { 0x34d59603, 0x1428, 0x4429, { 0xa4, 0x14, 0xe6, 0xb3, \
> +0xb5, 0xfd, 0x7d, 0xc1 } }
>  
>  typedef struct EFI_DRIVER_STOP_PROTOCOL_S  EFI_DRIVER_STOP_PROTOCOL;
>  

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 07/20] IntelUndiPkg/XGigUndiDxe: drop definition of gImageHandle

2019-01-30 Thread Ryszard Knop
Hmm, is there a list/something I can generate to see which globals
build tools emit? There are some more variables I'd happily get rid
of, eg if I could drop gSystemTable and others.

Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> Remove duplicate definition of gImageHandle, which is emitted by
> the build tools as well.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/Init.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/Init.c
> b/IntelUndiPkg/XGigUndiDxe/Init.c
> index 84e06ea071c5..03e3942a1944 100644
> --- a/IntelUndiPkg/XGigUndiDxe/Init.c
> +++ b/IntelUndiPkg/XGigUndiDxe/Init.c
> @@ -47,7 +47,6 @@ UINT16 mActiveChildren= 0;
>  EFI_EVENT  gEventNotifyExitBs;
>  EFI_EVENT  gEventNotifyVirtual;
>  
> -EFI_HANDLEgImageHandle;
>  EFI_SYSTEM_TABLE *gSystemTable;
>  
>  EFI_GUID gEfiNiiPointerGuid = EFI_NII_POINTER_PROTOCOL_GUID;
> @@ -502,7 +501,6 @@ InitializeXGigUndiDriver (
>  {
>EFI_STATUS Status;
>  
> -  gImageHandle  = ImageHandle;
>gSystemTable  = SystemTable;
>  
>Status = EfiLibInstallDriverBinding (ImageHandle, SystemTable,
> , ImageHandle);

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 06/20] IntelUndiPkg/XGigUndiDxe: add missing UINT8* cast

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> UINT8 and CHAR8 are not the same underlying type on all
> architectures,
> so add an explicit cast where necessary.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/Hii.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/Hii.c
> b/IntelUndiPkg/XGigUndiDxe/Hii.c
> index 3ad7d61e493d..3170580487d5 100644
> --- a/IntelUndiPkg/XGigUndiDxe/Hii.c
> +++ b/IntelUndiPkg/XGigUndiDxe/Hii.c
> @@ -782,7 +782,7 @@ HiiSetMenuStrings (
>  
>Status = ReadPbaString (
>   >NicInfo,
> - PBAString8,
> + (UINT8 *)PBAString8,
>   MAX_PBA_STR_LENGTH
> );
>if (Status == EFI_SUCCESS) {

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 05/20] IntelUndiPkg/XGigUndiDxe: add missing VOID** cast

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> Unlike Visual Studio, GCC does not permit implicit conversion between
> a pointer-to-void-pointer and pointer to a typed pointer. So add the
> explicit casts where necessary.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/Hii.c  | 8 
>  IntelUndiPkg/XGigUndiDxe/Init.c | 2 +-
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/Hii.c
> b/IntelUndiPkg/XGigUndiDxe/Hii.c
> index 857a475622f7..3ad7d61e493d 100644
> --- a/IntelUndiPkg/XGigUndiDxe/Hii.c
> +++ b/IntelUndiPkg/XGigUndiDxe/Hii.c
> @@ -459,7 +459,7 @@ HiiOpenProtocol (
>Status = gBS->LocateProtocol (
>,
>NULL,
> -  >HiiDatabase
> +  (VOID **)>HiiDatabase
>  );
>if (EFI_ERROR (Status)) {
>  DEBUGPRINT (CRITICAL, ("Error finding HII protocol: %r\n",
> Status));
> @@ -472,7 +472,7 @@ HiiOpenProtocol (
>Status = gBS->LocateProtocol (
>,
>NULL,
> -  >HiiString
> +  (VOID **)>HiiString
>  );
>if (EFI_ERROR (Status)) {
>  DEBUGPRINT (CRITICAL, ("Error finding HII String protocol:
> %r\n", Status));
> @@ -485,7 +485,7 @@ HiiOpenProtocol (
>Status = gBS->LocateProtocol (
>,
>NULL,
> -  >FormBrowser2
> +  (VOID **)>FormBrowser2
>  );
>if (EFI_ERROR (Status)) {
>  DEBUGPRINT (CRITICAL, ("Error finding HII form browser protocol:
> %r\n", Status));
> @@ -498,7 +498,7 @@ HiiOpenProtocol (
>Status = gBS->LocateProtocol (
>,
>NULL,
> -  >HiiConfigRouting
> +  (VOID **)>HiiConfigRouting
>  );
>if (EFI_ERROR (Status)) {
>  DEBUGPRINT (CRITICAL, ("Error finding HII ConfigRouting
> protocol: %r\n", Status));
> diff --git a/IntelUndiPkg/XGigUndiDxe/Init.c
> b/IntelUndiPkg/XGigUndiDxe/Init.c
> index bffe3c165866..84e06ea071c5 100644
> --- a/IntelUndiPkg/XGigUndiDxe/Init.c
> +++ b/IntelUndiPkg/XGigUndiDxe/Init.c
> @@ -179,7 +179,7 @@ InitAppendMac2DevPath (
>Status = gBS->AllocatePool (
>EfiBootServicesData,  // EfiRuntimeServicesData,
>TotalPathLen,
> -  
> +  (VOID **)
>  );
>  
>if (Status != EFI_SUCCESS) {

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 04/20] IntelUndiPkg/XGigUndiDxe: move BRAND_STRUCT declaration after type definition

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> Move the extern declaration of mBrandingTable[] after the definition
> of
> the type. This solves a build issue with GCC.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/DeviceSupport.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/DeviceSupport.h
> b/IntelUndiPkg/XGigUndiDxe/DeviceSupport.h
> index e997983ba3e7..d501d9bb1371 100644
> --- a/IntelUndiPkg/XGigUndiDxe/DeviceSupport.h
> +++ b/IntelUndiPkg/XGigUndiDxe/DeviceSupport.h
> @@ -33,9 +33,6 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
>  typedef struct BRAND_STRUCT_S BRAND_STRUCT;
>  
> -extern BRAND_STRUCT mBrandingTable[];
> -extern UINTNmBrandingTableSize;
> -
>  /* Defines */
>  #define INVALID_VENDOR_ID 0x
>  #define INVALID_SUBVENDOR_ID  0x
> @@ -53,6 +50,9 @@ struct BRAND_STRUCT_S {
>CHAR16 *BrandString;
>  };
>  
> +extern BRAND_STRUCT mBrandingTable[];
> +extern UINTNmBrandingTableSize;
> +
>  /* Function declarations */
>  
>  /** Returns pointer to current device's branding string (looks for
> best match)

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 03/20] IntelUndiPkg/XGigUndiDxe: consistently use forward slashes as path separators

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> Replace backslashes in paths with forward slashes to be compatible
> with
> non-Windows OSes.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/Decode.c|  2 +-
>  IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf | 14 +++---
>  IntelUndiPkg/XGigUndiDxe/Xgbe.h  |  2 +-
>  IntelUndiPkg/XGigUndiDxe/ixgbe_osdep.h   |  4 ++--
>  4 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/Decode.c
> b/IntelUndiPkg/XGigUndiDxe/Decode.c
> index 70fbce64c64f..5f37ce254872 100644
> --- a/IntelUndiPkg/XGigUndiDxe/Decode.c
> +++ b/IntelUndiPkg/XGigUndiDxe/Decode.c
> @@ -28,7 +28,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
> ***/
>  
>  #include "Xgbe.h"
> -#include 
> +#include 
>  
>  // Forward declarations for UNDI function table
>  /** This routine determines the operational state of the UNDI.  It
> updates the state flags in the
> diff --git a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> index 7ccc52bc9869..beee8aa8134e 100644
> --- a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> +++ b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> @@ -110,13 +110,13 @@ GCC:*_*_*_CC_FLAGS = -DEFI32
>   Version.h
>   HiiInternalLib.c
>   HiiInternalLib.h
> -  wol\wol.c
> -  wol\wol.h
> -  wol\wolfamily.c
> -  wol\wolimpl.c
> -  wol\wolimpl.h
> -  wol\wolinfo.c
> -  wol\wol_10G.c
> +  wol/wol.c
> +  wol/wol.h
> +  wol/wolfamily.c
> +  wol/wolimpl.c
> +  wol/wolimpl.h
> +  wol/wolinfo.c
> +  wol/wol_10G.c
>  
>  [Packages]
>MdePkg/MdePkg.dec
> diff --git a/IntelUndiPkg/XGigUndiDxe/Xgbe.h
> b/IntelUndiPkg/XGigUndiDxe/Xgbe.h
> index 5ab088362f90..4472cfb4fa31 100644
> --- a/IntelUndiPkg/XGigUndiDxe/Xgbe.h
> +++ b/IntelUndiPkg/XGigUndiDxe/Xgbe.h
> @@ -69,7 +69,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include 
>  
> diff --git a/IntelUndiPkg/XGigUndiDxe/ixgbe_osdep.h
> b/IntelUndiPkg/XGigUndiDxe/ixgbe_osdep.h
> index 368f40811904..e324b0539782 100644
> --- a/IntelUndiPkg/XGigUndiDxe/ixgbe_osdep.h
> +++ b/IntelUndiPkg/XGigUndiDxe/ixgbe_osdep.h
> @@ -39,8 +39,8 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
>  #include 
>  #include 
> -#include 
> -#include 
> +#include 
> +#include 
>  #include 
>  
>  #define CHARCHAR8

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 02/20] IntelUndiPkg/XGigUndiDxe: move MSFT warning overrides to INF file

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> GCC chokes on the unknown MSVC specific #pragmas used for suppressing
> warnings, so remove them and use the INF BuildOptions section
> instead.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf |  4 ++--
>  IntelUndiPkg/XGigUndiDxe/ixgbe_osdep.h   | 10 --
>  2 files changed, 2 insertions(+), 12 deletions(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> index ab9c64dac7e8..7ccc52bc9869 100644
> --- a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> +++ b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> @@ -44,7 +44,7 @@ UNLOAD_IMAGE = UnloadXGigUndiDriver
>  
>  [BuildOptions.common]
>  
> -MSFT:*_*_*_CC_FLAGS = /FAcs /D MDEPKG_NDEBUG /D UNDI_10G
> +MSFT:*_*_*_CC_FLAGS = /FAcs /D MDEPKG_NDEBUG /D UNDI_10G /wd4244
> /wd4206 /wd4189
>  GCC:*_*_*_CC_FLAGS = -DUNDI_10G
>  GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>  
> @@ -60,7 +60,7 @@ GCC:*_*_*_CC_FLAGS = -DEFI64
>  
>  [BuildOptions.IA32]
>  
> -MSFT:*_*_*_CC_FLAGS = /D EFI32
> +MSFT:*_*_*_CC_FLAGS = /D EFI32 /wd4305
>  GCC:*_*_*_CC_FLAGS = -DEFI32
>  
>  [sources.common]
> diff --git a/IntelUndiPkg/XGigUndiDxe/ixgbe_osdep.h
> b/IntelUndiPkg/XGigUndiDxe/ixgbe_osdep.h
> index 6fa0d1605c7c..368f40811904 100644
> --- a/IntelUndiPkg/XGigUndiDxe/ixgbe_osdep.h
> +++ b/IntelUndiPkg/XGigUndiDxe/ixgbe_osdep.h
> @@ -29,16 +29,6 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  #ifndef IXGBE_OSDEP_H_
>  #define IXGBE_OSDEP_H_
>  
> -#pragma warning(disable : 4244)
> -#pragma warning(disable : 4206)
> -#pragma warning(disable : 4189)
> -
> -#ifdef EFI32
> -
> -// Remove truncation warning in type cast when some 64 bit variables
> are converted to 32-bit pointers
> -#pragma warning(disable : 4305)
> -#endif /* EFI32 */
> -
>  #ifndef EFI_SPECIFICATION_VERSION
>  #define EFI_SPECIFICATION_VERSION 0x0002
>  #endif /* EFI_SPECIFICATION_VERSION */

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 01/20] IntelUndiPkg/XGigUndiDxe: create GCC alternatives for MSFT build options

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
> Prefix the existing MSFT-only build option overrides with MSFT: and
> create the GCC: counterparts so we can build this code with GCC as
> well.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> index 9e0e4aff0885..ab9c64dac7e8 100644
> --- a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> +++ b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf
> @@ -44,19 +44,24 @@ UNLOAD_IMAGE = UnloadXGigUndiDriver
>  
>  [BuildOptions.common]
>  
> -*_*_*_CC_FLAGS = /FAcs /D MDEPKG_NDEBUG /D UNDI_10G
> +MSFT:*_*_*_CC_FLAGS = /FAcs /D MDEPKG_NDEBUG /D UNDI_10G
> +GCC:*_*_*_CC_FLAGS = -DUNDI_10G
> +GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>  
>  [BuildOptions.X64]
>  
> -*_*_*_CC_FLAGS = /D EFIX64 
> +MSFT:*_*_*_CC_FLAGS = /D EFIX64
> +GCC:*_*_*_CC_FLAGS = -DEFIX64
>  
>  [BuildOptions.IPF]
>  
> -*_*_*_CC_FLAGS = /D EFI64
> +MSFT:*_*_*_CC_FLAGS = /D EFI64
> +GCC:*_*_*_CC_FLAGS = -DEFI64
>  
>  [BuildOptions.IA32]
>  
> -*_*_*_CC_FLAGS = /D EFI32
> +MSFT:*_*_*_CC_FLAGS = /D EFI32
> +GCC:*_*_*_CC_FLAGS = -DEFI32
>  
>  [sources.common]
>   InventoryStrings.uni

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 18/19] IntelUndiPkg/GigUndiDxe: add missing EFIAPI modifiers

2019-01-30 Thread Ryszard Knop
Builds were fine, the result didn't work. Adding proper EFIAPIs fixed
that, so should be okay everywhere.

On Wed, 2019-01-30 at 16:20 +0100, Ard Biesheuvel wrote:
> On Wed, 30 Jan 2019 at 16:15, Ryszard Knop <
> ryszard.k...@linux.intel.com> wrote:
> > I'm going through all the protocols we have defined/used and in
> > Decode.c/h there's [E1000]UndiApiEntry for PXE/UNDI callbacks. I've
> > tested an X64 GCC build under OVMF and these calls were broken due
> > to
> > mismatched calling conventions. Did this work correctly for your
> > builds
> > on your platforms?
> > 
> 
> Do you mean the builds were broken? Or the resulting builds didn't
> work?
> 
> In any case, that issue only exists on X64, since there are different
> SysV and MS calling conventions. and GCC uses the former by default.
> On ARM, there is no such difference.
> 
> > Reviewed-by: Ryszard Knop 
> > 
> > On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Ard Biesheuvel 
> > > ---
> > >  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  | 3 +++
> > >  IntelUndiPkg/GigUndiDxe/ComponentName.c   | 2 ++
> > >  IntelUndiPkg/GigUndiDxe/ComponentName.h   | 1 +
> > >  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c | 3 +++
> > >  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 1 +
> > >  IntelUndiPkg/GigUndiDxe/DriverHealth.c| 2 ++
> > >  IntelUndiPkg/GigUndiDxe/StartStop.c   | 2 ++
> > >  7 files changed, 14 insertions(+)
> > > 
> > > diff --git a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> > > b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> > > index 8918c538e447..1cece79911b1 100644
> > > --- a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> > > +++ b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> > > @@ -123,6 +123,7 @@ GetIpv6SupportInformationBlock (
> > >  **/
> > >  STATIC
> > >  EFI_STATUS
> > > +EFIAPI
> > >  GetInformation (
> > >IN  EFI_ADAPTER_INFORMATION_PROTOCOL *This,
> > >IN  EFI_GUID *InformationType,
> > > @@ -188,6 +189,7 @@ GetInformation (
> > >  **/
> > >  STATIC
> > >  EFI_STATUS
> > > +EFIAPI
> > >  SetInformation (
> > >IN  EFI_ADAPTER_INFORMATION_PROTOCOL *This,
> > >IN  EFI_GUID *InformationType,
> > > @@ -234,6 +236,7 @@ SetInformation (
> > >  **/
> > >  STATIC
> > >  EFI_STATUS
> > > +EFIAPI
> > >  GetSupportedTypes (
> > >IN  EFI_ADAPTER_INFORMATION_PROTOCOL *This,
> > >OUT EFI_GUID **   InfoTypesBuffer,
> > > diff --git a/IntelUndiPkg/GigUndiDxe/ComponentName.c
> > > b/IntelUndiPkg/GigUndiDxe/ComponentName.c
> > > index 70baf00f4a5d..2bf9bbfbe0e4 100644
> > > --- a/IntelUndiPkg/GigUndiDxe/ComponentName.c
> > > +++ b/IntelUndiPkg/GigUndiDxe/ComponentName.c
> > > @@ -112,6 +112,7 @@ ComponentNameInitializeControllerName (
> > >  language specified by
> > > Language.
> > >  **/
> > >  EFI_STATUS
> > > +EFIAPI
> > >  ComponentNameGetDriverName (
> > >IN  EFI_COMPONENT_NAME_PROTOCOL *This,
> > >IN  CHAR8 *  Language,
> > > @@ -182,6 +183,7 @@ ComponentNameGetDriverName (
> > >  language specified by
> > > Language.
> > >  **/
> > >  EFI_STATUS
> > > +EFIAPI
> > >  ComponentNameGetControllerName (
> > >IN  EFI_COMPONENT_NAME_PROTOCOL
> > > *   This,
> > >IN  EFI_HANDLE
> > >   Co
> > > ntrollerHandle,
> > > diff --git a/IntelUndiPkg/GigUndiDxe/ComponentName.h
> > > b/IntelUndiPkg/GigUndiDxe/ComponentName.h
> > > index 5a3d414c6970..0b93a5410fc0 100644
> > > --- a/IntelUndiPkg/GigUndiDxe/ComponentName.h
> > > +++ b/IntelUndiPkg/GigUndiDxe/ComponentName.h
> > > @@ -65,6 +65,7 @@ ComponentNameInitializeControllerName (
> > >  language specified by
> > > Language.
> > >  **/
> > >  EFI_STATUS
> > > +EFIAPI
> > >  ComponentNameGetDriverName (
> > >IN  EFI_COMPONENT_NAME_PROTOCOL *This,
> > >IN  CHAR8 *  Language,
> > > diff

Re: [edk2] [PATCH edk2-staging 15/19] IntelUndiPkg/GigUndiDxe: remove forward declaration of non-existent function

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Remove the forward declaration of e1000_disable_ulp_lpt_lp (), which
> is never defined anywhere in the code.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
> b/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
> index 7669630a5c03..e9fc5394ab28 100644
> --- a/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
> +++ b/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
> @@ -103,9 +103,6 @@ STATIC s32  e1000_reset_hw_ich8lan(struct
> e1000_hw *hw);
>  STATIC s32  e1000_init_hw_ich8lan(struct e1000_hw *hw);
>  STATIC s32  e1000_setup_link_ich8lan(struct e1000_hw *hw);
>  STATIC s32  e1000_setup_copper_link_ich8lan(struct e1000_hw *hw);
> -#if !defined(NO_ULP_IN_S5_SUPPORT) 
> -STATIC s32 e1000_disable_ulp_lpt_lp(struct e1000_hw *hw, bool
> force);
> -#endif /* !NO_ULP_IN_S5_SUPPORT && !ULP_IN_D0_SUPPORT */
>  STATIC s32  e1000_setup_copper_link_pch_lpt(struct e1000_hw *hw);
>  STATIC s32  e1000_get_link_up_info_ich8lan(struct e1000_hw *hw,
>  u16 *speed, u16 *duplex);

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 18/19] IntelUndiPkg/GigUndiDxe: add missing EFIAPI modifiers

2019-01-30 Thread Ryszard Knop
I'm going through all the protocols we have defined/used and in
Decode.c/h there's [E1000]UndiApiEntry for PXE/UNDI callbacks. I've
tested an X64 GCC build under OVMF and these calls were broken due to
mismatched calling conventions. Did this work correctly for your builds
on your platforms?

Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  | 3 +++
>  IntelUndiPkg/GigUndiDxe/ComponentName.c   | 2 ++
>  IntelUndiPkg/GigUndiDxe/ComponentName.h   | 1 +
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c | 3 +++
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 1 +
>  IntelUndiPkg/GigUndiDxe/DriverHealth.c| 2 ++
>  IntelUndiPkg/GigUndiDxe/StartStop.c   | 2 ++
>  7 files changed, 14 insertions(+)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> index 8918c538e447..1cece79911b1 100644
> --- a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> +++ b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> @@ -123,6 +123,7 @@ GetIpv6SupportInformationBlock (
>  **/
>  STATIC
>  EFI_STATUS
> +EFIAPI
>  GetInformation (
>IN  EFI_ADAPTER_INFORMATION_PROTOCOL *This,
>IN  EFI_GUID *InformationType,
> @@ -188,6 +189,7 @@ GetInformation (
>  **/
>  STATIC
>  EFI_STATUS
> +EFIAPI
>  SetInformation (
>IN  EFI_ADAPTER_INFORMATION_PROTOCOL *This,
>IN  EFI_GUID *InformationType,
> @@ -234,6 +236,7 @@ SetInformation (
>  **/
>  STATIC
>  EFI_STATUS
> +EFIAPI
>  GetSupportedTypes (
>IN  EFI_ADAPTER_INFORMATION_PROTOCOL *This,
>OUT EFI_GUID **   InfoTypesBuffer,
> diff --git a/IntelUndiPkg/GigUndiDxe/ComponentName.c
> b/IntelUndiPkg/GigUndiDxe/ComponentName.c
> index 70baf00f4a5d..2bf9bbfbe0e4 100644
> --- a/IntelUndiPkg/GigUndiDxe/ComponentName.c
> +++ b/IntelUndiPkg/GigUndiDxe/ComponentName.c
> @@ -112,6 +112,7 @@ ComponentNameInitializeControllerName (
>  language specified by Language.
>  **/
>  EFI_STATUS
> +EFIAPI
>  ComponentNameGetDriverName (
>IN  EFI_COMPONENT_NAME_PROTOCOL *This,
>IN  CHAR8 *  Language,
> @@ -182,6 +183,7 @@ ComponentNameGetDriverName (
>  language specified by Language.
>  **/
>  EFI_STATUS
> +EFIAPI
>  ComponentNameGetControllerName (
>IN  EFI_COMPONENT_NAME_PROTOCOL
> *   This,
>IN  EFI_HANDLE  Co
> ntrollerHandle,
> diff --git a/IntelUndiPkg/GigUndiDxe/ComponentName.h
> b/IntelUndiPkg/GigUndiDxe/ComponentName.h
> index 5a3d414c6970..0b93a5410fc0 100644
> --- a/IntelUndiPkg/GigUndiDxe/ComponentName.h
> +++ b/IntelUndiPkg/GigUndiDxe/ComponentName.h
> @@ -65,6 +65,7 @@ ComponentNameInitializeControllerName (
>  language specified by Language.
>  **/
>  EFI_STATUS
> +EFIAPI
>  ComponentNameGetDriverName (
>IN  EFI_COMPONENT_NAME_PROTOCOL *This,
>IN  CHAR8 *  Language,
> diff --git a/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
> b/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
> index 20d40ab672ef..99e086d81044 100644
> --- a/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
> +++ b/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
> @@ -310,6 +310,7 @@ GigUndiDriverConfigurationDisplayMenu (
> @retval   EFI_SUCCESS   Configuration was successful
>  **/
>  EFI_STATUS
> +EFIAPI
>  GigUndiDriverConfigurationSetOptions (
>IN EFI_DRIVER_CONFIGURATION_PROTOCOL *  This,
>IN EFI_HANDLE   ControllerHandle,
> @@ -418,6 +419,7 @@ GigUndiDriverConfigurationSetOptions (
> @retval   EFI_SUCCESS   Always returned
>  **/
>  EFI_STATUS
> +EFIAPI
>  GigUndiDriverConfigurationOptionsValid (
>IN EFI_DRIVER_CONFIGURATION_PROTOCOL *   This,
>IN EFI_HANDLEControllerHandle,
> @@ -442,6 +444,7 @@ GigUndiDriverConfigurationOptionsValid (
> @retval   EFI_SUCCESS   Configuration was successful
>  **/
>  EFI_STATUS
> +EFIAPI
>  GigUndiDriverConfigurationForceDefaults (
>IN EFI_DRIVER_CONFIGURATION_PROTOCOL *   This,
>IN
> EFI_HANDLEControllerHandl
> e,
> diff --git a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
> b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
> index aceb015e480f..f6152cd24c59 100644
> --- a/IntelUndiPkg/GigUndiDxe/

Re: [edk2] [PATCH edk2-staging 19/19] IntelUndiPkg/GigUndiDxe: remove or reorganize unused variables

2019-01-30 Thread Ryszard Knop
Just one thing - in E1000Receive, the removed Status is actually
needed, we've missed the error handling block in 1G while backporting
DMA changes from 40G drivers.

Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Drop variables that are assigned but never used, or move them into
> a conditional preprocessor block if the only references occur from
> such code.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c |  2 --
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.c|  2 --
>  IntelUndiPkg/GigUndiDxe/e1000.c | 16 +++-
>  3 files changed, 7 insertions(+), 13 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
> b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
> index f6152cd24c59..af8aaa797e68 100644
> --- a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
> +++ b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
> @@ -1123,11 +1123,9 @@ GigUndiRunPhyLoopback (
>UINT64   FreeTxBuffer[DEFAULT_TX_DESCRIPTORS];
>UINT32   j;
>UINT32   i;
> -  struct e1000_hw *Hw;
>  
>Status  = EFI_SUCCESS;
>j   = 0;
> -  Hw = >Hw;
>  
>while (j < PHY_LOOPBACK_ITERATIONS) {
>  Status = E1000Transmit (
> diff --git a/IntelUndiPkg/GigUndiDxe/HiiInternalLib.c
> b/IntelUndiPkg/GigUndiDxe/HiiInternalLib.c
> index 2aacb63ca158..690d8314be74 100644
> --- a/IntelUndiPkg/GigUndiDxe/HiiInternalLib.c
> +++ b/IntelUndiPkg/GigUndiDxe/HiiInternalLib.c
> @@ -197,7 +197,6 @@ GetNextRequestElement (
>)
>  {
>EFI_STRING StringPtr;
> -  EFI_STRING TmpPtr;
>EFI_STATUS Status;
>UINTN  Length;
>UINT8 *TmpBuffer;
> @@ -227,7 +226,6 @@ GetNextRequestElement (
>}
>  
>// Back up the header of one 
> -  TmpPtr = StringPtr;
>  
>StringPtr += StrLen (L"OFFSET=");
>  
> diff --git a/IntelUndiPkg/GigUndiDxe/e1000.c
> b/IntelUndiPkg/GigUndiDxe/e1000.c
> index 28c900e3ad63..3d4a21c62d77 100644
> --- a/IntelUndiPkg/GigUndiDxe/e1000.c
> +++ b/IntelUndiPkg/GigUndiDxe/e1000.c
> @@ -412,7 +412,6 @@ E1000Transmit (
>E1000_TRANSMIT_DESCRIPTOR  *TransmitDescriptor;
>UINT32  i;
>INT16   WaitMsec;
> -  EFI_STATUS  Status;
>UNDI_DMA_MAPPING*TxBufMapping;
>  
>TxBufMapping = >TxBufferMappings[GigAdapter-
> >CurTxInd];
> @@ -483,7 +482,7 @@ E1000Transmit (
>  TxBufMapping->Size = TxBuffer->DataLen + TxBuffer-
> >MediaheaderLen;
>  
>  // Make the Tx buffer accessible for adapter over DMA
> -Status = UndiDmaMapMemoryRead (
> +UndiDmaMapMemoryRead (
> GigAdapter->PciIo,
> TxBufMapping
> );
> @@ -594,20 +593,21 @@ E1000Receive (
>E1000_RECEIVE_DESCRIPTOR *ReceiveDescriptor;
>ETHER_HEADER *EtherHeader;
>PXE_STATCODE  StatCode;
> -  UINT16i;
>UINT16TempLen;
> +#if (DBG_LVL & RX)
> +  UINT16i;
>UINT8 *   PacketPtr;
>  #if (DBG_LVL & CRITICAL)
> -#if (DBG_LVL & RX)
>UINT32 Rdh;
>UINT32 Rdt;
> -#endif /* (DBG_LVL & RX) */
> +
>  #endif /* (DBG_LVL & CRITICAL) */
> +  i   = 0;
> +#endif /* (DBG_LVL & RX) */
>  
>  
>PacketType  = PXE_FRAME_TYPE_NONE;
>StatCode= PXE_STATCODE_NO_DATA;
> -  i   = 0;
>  
>// acknowledge the interrupts
>E1000_READ_REG (>Hw, E1000_ICR);
> @@ -679,9 +679,9 @@ E1000Receive (
>  TempLen
>);
>  
> +#if (DBG_LVL & RX)
>PacketPtr = (UINT8 *) (UINTN) CpbReceive->BufferAddr;
>  
> -#if (DBG_LVL & RX)
>DEBUGPRINT (RX, ("Packet Data \n"));
>for (i = 0; i < TempLen; i++) {
>  DEBUGPRINT (RX, ("%x ", PacketPtr[i]));
> @@ -1569,13 +1569,11 @@ E1000Inititialize (
>GIG_DRIVER_DATA *GigAdapter
>)
>  {
> -  UINT32 * TempBar;
>PXE_STATCODE PxeStatcode;
>  
>DEBUGPRINT (E1000, ("E1000Inititialize\n"));
>  
>PxeStatcode = PXE_STATCODE_SUCCESS;
> -  TempBar = NULL;
>  
>ZeroMem (
>  (VOID *)(UINTN)GigAdapter->RxRing.UnmappedAddress,

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 17/19] IntelUndiPkg/GigUndiDxe: move MSFT warning overrides to INF file

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> GCC chokes on the unknown MSVC specific #pragmas used for suppressing
> warnings, so remove them and use the INF BuildOptions section
> instead.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf | 2 +-
>  IntelUndiPkg/GigUndiDxe/e1000_osdep.h  | 3 ---
>  2 files changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> index 19dae9a0987a..9159e826ec45 100644
> --- a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> +++ b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> @@ -41,7 +41,7 @@ ENTRY_POINT  = InitializeGigUNDIDriver
>  UNLOAD_IMAGE = GigUndiUnload
>  
>  [BuildOptions.common]
> -  MSFT:*_*_*_CC_FLAGS = /FAcs /D MDEPKG_NDEBUG
> +  MSFT:*_*_*_CC_FLAGS = /FAcs /D MDEPKG_NDEBUG /wd4244 /wd4206
>GCC:RELEASE_*_*_CC_FLAGS = -D MDEPKG_NDEBUG
>  
>  [BuildOptions.X64]
> diff --git a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
> b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
> index 4408b409a445..70f33811dd04 100644
> --- a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
> +++ b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
> @@ -34,9 +34,6 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  #include 
>  #include 
>  
> -#pragma warning(disable : 4244)
> -#pragma warning(disable : 4206)
> -
>  #ifndef EFI_SPECIFICATION_VERSION
>  #define EFI_SPECIFICATION_VERSION 0x0002
>  #endif /* EFI_SPECIFICATION_VERSION */

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 13/19] IntelUndiPkg/GigUndiDxe: don't take address of cast expression

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Taking the address of a cast expression is not permitted in C.
> Instead,
> take the address of the variable, and cast the pointer to the desired
> pointer type.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/e1000.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/e1000.c
> b/IntelUndiPkg/GigUndiDxe/e1000.c
> index 4c9a06b8cf73..28c900e3ad63 100644
> --- a/IntelUndiPkg/GigUndiDxe/e1000.c
> +++ b/IntelUndiPkg/GigUndiDxe/e1000.c
> @@ -1107,7 +1107,7 @@ E1000TxRxConfigure (
>// Set the MemPtr to the high dword of the rx_ring so we can store
> it in RDBAH0.
>// Right shifts do not seem to work with the EFI compiler so we do
> it like this for now.
>MemAddr = (UINT64) (UINTN) GigAdapter->RxRing.PhysicalAddress;
> -  MemPtr  = &((UINT32) MemAddr);
> +  MemPtr  = (UINT32 *)
>MemPtr++;
>E1000_WRITE_REG (>Hw, E1000_RDBAH (0), *MemPtr);
>  
> @@ -1185,7 +1185,7 @@ E1000TxRxConfigure (
>  
>E1000_WRITE_REG (>Hw, E1000_TDBAL (0), (UINT32)
> (UINTN) (GigAdapter->TxRing.PhysicalAddress));
>MemAddr = (UINT64) (UINTN) GigAdapter->TxRing.PhysicalAddress;
> -  MemPtr  = &((UINT32) MemAddr);
> +  MemPtr  = (UINT32 *)
>MemPtr++;
>E1000_WRITE_REG (>Hw, E1000_TDBAH (0), *MemPtr);
>DEBUGPRINT (E1000, ("TdBah0 %X\n", *MemPtr));

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 12/19] IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to correct pointer type

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> E1000MemCopy () takes UINT8 pointers not INT8 pointers, so cast the
> arguments to the correct type.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/e1000.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/e1000.c
> b/IntelUndiPkg/GigUndiDxe/e1000.c
> index 1f08a5d67b2d..4c9a06b8cf73 100644
> --- a/IntelUndiPkg/GigUndiDxe/e1000.c
> +++ b/IntelUndiPkg/GigUndiDxe/e1000.c
> @@ -674,8 +674,8 @@ E1000Receive (
>  
>// Copy the packet from our list to the EFI buffer.
>E1000MemCopy (
> -(INT8 *) (UINTN) CpbReceive->BufferAddr,
> -(INT8 *) (UINTN) ReceiveDescriptor->buffer_addr,
> +(UINT8 *) (UINTN) CpbReceive->BufferAddr,
> +(UINT8 *) (UINTN) ReceiveDescriptor->buffer_addr,
>  TempLen
>);
>  

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 11/19] IntelUndiPkg/GigUndiDxe: fix incorrect use of CPP token pasting

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> The ## CPP token pasting operator is used to paste *tokens*, which
> is not the same thing as pasting arbitrary macro arguments. Since a
> token cannot contain . or ) characters in the first place, using
> the ## operator here is wrong and unnecessary, so just remove it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/NVDataStruc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
> b/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
> index 72f6a95ccb6d..04f08b41c842 100644
> --- a/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
> +++ b/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
> @@ -112,7 +112,7 @@ typedef struct {
>  
> @return   Width of given field is returned
>  **/
> -#define UNDI_CONFIG_WIDTH(Field) sizeof (UndiPrivateData-
> >Configuration. ## Field ## )
> +#define UNDI_CONFIG_WIDTH(Field) sizeof (UndiPrivateData-
> >Configuration.Field)
>  
>  // General parameters
>  #define QUESTION_ID_EFI_DRIVER_VER  0x11
> 00

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 10/19] IntelUndiPkg/GigUndiDxe: add missing braces to GUID literals

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> The Data4 member of the GUID/EFI_GUID struct type is an array of
> UINT8, so literals require two sets of { } braces. Add them where
> missing.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/NVDataStruc.h | 4 ++--
>  IntelUndiPkg/GigUndiDxe/StartStop.h   | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
> b/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
> index bd7d4defc9a3..72f6a95ccb6d 100644
> --- a/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
> +++ b/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
> @@ -34,12 +34,12 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
>  #define E1000_HII_FORM_GUID \
>{ \
> -0x77f2ea2f, 0x4312, 0x4569, 0x85, 0xc4, 0x58, 0x3a, 0xcd, 0x8d,
> 0xb7, 0xe2 \
> +0x77f2ea2f, 0x4312, 0x4569, { 0x85, 0xc4, 0x58, 0x3a, 0xcd,
> 0x8d, 0xb7, 0xe2 } \
>}
>  
>  #define E1000_HII_DATA_GUID \
>{ \
> -0xa31abb16, 0xc627, 0x475b, 0x98, 0x8e, 0x7e, 0xe0, 0x77, 0x67,
> 0x40, 0xf3 \
> +0xa31abb16, 0xc627, 0x475b, { 0x98, 0x8e, 0x7e, 0xe0, 0x77,
> 0x67, 0x40, 0xf3 } \
>}
>  
>  
> diff --git a/IntelUndiPkg/GigUndiDxe/StartStop.h
> b/IntelUndiPkg/GigUndiDxe/StartStop.h
> index 255f17aabaa4..b29a5002bb8e 100644
> --- a/IntelUndiPkg/GigUndiDxe/StartStop.h
> +++ b/IntelUndiPkg/GigUndiDxe/StartStop.h
> @@ -32,8 +32,8 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  #include "e1000.h"
>  
>  #define EFI_DRIVER_STOP_PROTOCOL_GUID \
> -{ 0x34d59603, 0x1428, 0x4429, 0xa4, 0x14, 0xe6, 0xb3, \
> -0xb5, 0xfd, 0x7d, 0xc1 }
> +{ 0x34d59603, 0x1428, 0x4429, { 0xa4, 0x14, 0xe6, 0xb3, \
> +0xb5, 0xfd, 0x7d, 0xc1 } }
>  
>  typedef struct EFI_DRIVER_STOP_PROTOCOL_S  EFI_DRIVER_STOP_PROTOCOL;
>  

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 09/19] IntelUndiPkg/GigUndiDxe: add missing UINT8* cast

2019-01-30 Thread Ryszard Knop
On Tue, 2018-11-06 at 21:31 +0100, philmd at redhat.com wrote:
> Hi Ard,
> 
> On 6/11/18 18:58, Ard Biesheuvel wrote:
> > UINT8 and CHAR8 are not the same underlying type on all
> > architectures,
> > so add an explicit cast where necessary.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >   IntelUndiPkg/GigUndiDxe/Hii.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/IntelUndiPkg/GigUndiDxe/Hii.c
> > b/IntelUndiPkg/GigUndiDxe/Hii.c
> > index a5d8ae207819..737a59fbbbac 100644
> > --- a/IntelUndiPkg/GigUndiDxe/Hii.c
> > +++ b/IntelUndiPkg/GigUndiDxe/Hii.c
> > @@ -817,7 +817,7 @@ HiiSetMenuStrings (
> >   
> > Status = ReadPbaString (
> >>NicInfo,
> > - PBAString8,
> > + (UINT8 *)PBAString8,
> >MAX_PBA_STR_LENGTH
> >  );
> > if (Status == EFI_SUCCESS) {
> > 
> 
> I'm not sure why ReadPbaString() takes UINT8* instead of CHAR8*.
> Having the device part number stored into a CHAR8[] seems correct,
> what 
> do you think?
I agree that it should use CHAR8, but the underlying code in
e1000_nvm.c is shared between multiple drivers expecting uint8_t or
equivalent, so as Ard said it'd just move the problem elsewhere. It'd
be nice to keep this conversion in ReadPbaString, but as this is the
only place where this function is used, it's fine for now. Hii.c and
friends overall need some solid refactoring if time allows.


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 09/19] IntelUndiPkg/GigUndiDxe: add missing UINT8* cast

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> UINT8 and CHAR8 are not the same underlying type on all
> architectures,
> so add an explicit cast where necessary.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/Hii.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/Hii.c
> b/IntelUndiPkg/GigUndiDxe/Hii.c
> index a5d8ae207819..737a59fbbbac 100644
> --- a/IntelUndiPkg/GigUndiDxe/Hii.c
> +++ b/IntelUndiPkg/GigUndiDxe/Hii.c
> @@ -817,7 +817,7 @@ HiiSetMenuStrings (
>  
>Status = ReadPbaString (
>   >NicInfo,
> - PBAString8,
> + (UINT8 *)PBAString8,
>   MAX_PBA_STR_LENGTH
> );
>if (Status == EFI_SUCCESS) {

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 08/19] IntelUndiPkg/GigUndiDxe: add missing VOID** cast

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Unlike Visual Studio, GCC does not permit implicit conversion between
> a pointer-to-void-pointer and pointer to a typed pointer. So add the
> explicit casts where necessary.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/Hii.c  | 8 
>  IntelUndiPkg/GigUndiDxe/Init.c | 2 +-
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/Hii.c
> b/IntelUndiPkg/GigUndiDxe/Hii.c
> index 43c184cb03c8..a5d8ae207819 100644
> --- a/IntelUndiPkg/GigUndiDxe/Hii.c
> +++ b/IntelUndiPkg/GigUndiDxe/Hii.c
> @@ -459,7 +459,7 @@ HiiOpenProtocol (
>Status = gBS->LocateProtocol (
>,
>NULL,
> -  >HiiDatabase
> +  (VOID **)>HiiDatabase
>  );
>if (EFI_ERROR (Status)) {
>  DEBUGPRINT (CRITICAL, ("Error finding HII protocol: %r\n",
> Status));
> @@ -472,7 +472,7 @@ HiiOpenProtocol (
>Status = gBS->LocateProtocol (
>,
>NULL,
> -  >HiiString
> +  (VOID **)>HiiString
>  );
>if (EFI_ERROR (Status)) {
>  DEBUGPRINT (CRITICAL, ("Error finding HII String protocol:
> %r\n", Status));
> @@ -485,7 +485,7 @@ HiiOpenProtocol (
>Status = gBS->LocateProtocol (
>,
>NULL,
> -  >FormBrowser2
> +  (VOID **)>FormBrowser2
>  );
>if (EFI_ERROR (Status)) {
>  DEBUGPRINT (CRITICAL, ("Error finding HII form browser protocol:
> %r\n", Status));
> @@ -498,7 +498,7 @@ HiiOpenProtocol (
>Status = gBS->LocateProtocol (
>,
>NULL,
> -  >HiiConfigRouting
> +  (VOID **)>HiiConfigRouting
>  );
>if (EFI_ERROR (Status)) {
>  DEBUGPRINT (CRITICAL, ("Error finding HII ConfigRouting
> protocol: %r\n", Status));
> diff --git a/IntelUndiPkg/GigUndiDxe/Init.c
> b/IntelUndiPkg/GigUndiDxe/Init.c
> index f99734d72823..1de424c26fe2 100644
> --- a/IntelUndiPkg/GigUndiDxe/Init.c
> +++ b/IntelUndiPkg/GigUndiDxe/Init.c
> @@ -177,7 +177,7 @@ GigAppendMac2DevPath (
>Status = gBS->AllocatePool (
>EfiBootServicesData, // EfiRuntimeServicesData,
>TotalPathLen,
> -  
> +  (VOID **)
>  );
>  
>if (Status != EFI_SUCCESS) {

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 07/19] IntelUndiPkg/GigUndiDxe: create GCC alternatives for MSFT build options

2019-01-30 Thread Ryszard Knop
Just one note for this: We have separate defines for EFI32 (IA32),
EFI64 (IPF) and EFIX64 (X64) to sprinkle some workarounds where needed.
It seems ARM doesn't need that for now, but I'll add similar defines
for it as well so that we have that available in the future.

Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Prefix the existing MSFT only build option overrides with MSFT: and
> create the GCC: counterparts so we can build this code with GCC as
> well.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> index 6c195872c00f..19dae9a0987a 100644
> --- a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> +++ b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> @@ -41,20 +41,20 @@ ENTRY_POINT  = InitializeGigUNDIDriver
>  UNLOAD_IMAGE = GigUndiUnload
>  
>  [BuildOptions.common]
> -
> -*_*_*_CC_FLAGS = /FAcs /D MDEPKG_NDEBUG
> +  MSFT:*_*_*_CC_FLAGS = /FAcs /D MDEPKG_NDEBUG
> +  GCC:RELEASE_*_*_CC_FLAGS = -D MDEPKG_NDEBUG
>  
>  [BuildOptions.X64]
> -
> -*_*_*_CC_FLAGS = /D EFIX64 
> +  MSFT:*_*_*_CC_FLAGS = /D EFIX64
> +  GCC:*_*_*_CC_FLAGS = -D EFIX64
>  
>  [BuildOptions.IPF]
> -
> -*_*_*_CC_FLAGS = /D EFI64
> +  MSFT:*_*_*_CC_FLAGS = /D EFI64
> +  GCC:*_*_*_CC_FLAGS = -D EFI64
>  
>  [BuildOptions.IA32]
> -
> -*_*_*_CC_FLAGS = /D EFI32
> +  MSFT:*_*_*_CC_FLAGS = /D EFI32
> +  GCC:*_*_*_CC_FLAGS = -D EFI32
>  
>  [sources.common]
>  InventoryStrings.uni

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 06/19] IntelUndiPkg/GigUndiDxe: use intermediate UINTN casts for pointers

2019-01-30 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Use intermediate (UINTN) casts when casting pointers to UINT64.
> This is needed to be able to build this code for 32-bit architectures
> such as ARM or IA32.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/Dma.c   |  8 
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c |  6 +++---
>  IntelUndiPkg/GigUndiDxe/Init.c  |  6 +++---
>  IntelUndiPkg/GigUndiDxe/e1000.c | 10 +-
>  IntelUndiPkg/GigUndiDxe/e1000.h |  4 ++--
>  5 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/Dma.c
> b/IntelUndiPkg/GigUndiDxe/Dma.c
> index bf94c1e2fd54..eee2aa8a1ce3 100644
> --- a/IntelUndiPkg/GigUndiDxe/Dma.c
> +++ b/IntelUndiPkg/GigUndiDxe/Dma.c
> @@ -127,7 +127,7 @@ FREE_BUF_ON_ERROR:
>PciIo->FreeBuffer (
> PciIo,
> BytesToPages (DmaMapping->Size),
> -   (VOID *) DmaMapping->UnmappedAddress
> +   (VOID *)(UINTN)DmaMapping->UnmappedAddress
> );
>DmaMapping->Size = 0;
>DmaMapping->UnmappedAddress = 0;
> @@ -173,7 +173,7 @@ UndiDmaFreeCommonBuffer (
>PciIo->FreeBuffer (
> PciIo,
> BytesToPages (DmaMapping->Size),
> -   (VOID *) DmaMapping->UnmappedAddress
> +   (VOID *)(UINTN)DmaMapping->UnmappedAddress
> );
>  
>DmaMapping->UnmappedAddress = 0;
> @@ -209,7 +209,7 @@ UndiDmaMapCommonBuffer (
>return PciIo->Map (
>PciIo,
>EfiPciIoOperationBusMasterCommonBuffer,
> -  (VOID *) DmaMapping->UnmappedAddress,
> +  (VOID *)(UINTN)DmaMapping->UnmappedAddress,
>>Size,
>>PhysicalAddress,
>>Mapping
> @@ -243,7 +243,7 @@ UndiDmaMapMemoryRead (
>return PciIo->Map (
>PciIo,
>EfiPciIoOperationBusMasterRead,
> -  (VOID *) DmaMapping->UnmappedAddress,
> +  (VOID *)(UINTN)DmaMapping->UnmappedAddress,
>>Size,
>>PhysicalAddress,
>>Mapping
> diff --git a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
> b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
> index 559f2133281e..aceb015e480f 100644
> --- a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
> +++ b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
> @@ -1132,7 +1132,7 @@ GigUndiRunPhyLoopback (
>while (j < PHY_LOOPBACK_ITERATIONS) {
>  Status = E1000Transmit (
> GigAdapterInfo,
> -   (UINT64) ,
> +   (UINT64)(UINTN),
> PXE_OPFLAGS_TRANSMIT_WHOLE
>   );
>  _DisplayBuffersAndDescriptors (GigAdapterInfo);
> @@ -1161,8 +1161,8 @@ GigUndiRunPhyLoopback (
>  for (i = 0; i <= 10; i++) {
>Status = E1000Receive (
>   GigAdapterInfo,
> - (UINT64) ,
> - (UINT64) 
> + (UINT64)(UINTN),
> + (UINT64)(UINTN)
> );
>gBS->Stall (10);
>  
> diff --git a/IntelUndiPkg/GigUndiDxe/Init.c
> b/IntelUndiPkg/GigUndiDxe/Init.c
> index 74b933674589..f99734d72823 100644
> --- a/IntelUndiPkg/GigUndiDxe/Init.c
> +++ b/IntelUndiPkg/GigUndiDxe/Init.c
> @@ -301,7 +301,7 @@ GigUndiPxeStructInit (
> PXE_ROMID_IMP_TX_COMPLETE_INT_SUPPORTED |
> PXE_ROMID_IMP_PACKET_RX_INT_SUPPORTED;
>  
> -  PxePtr->EntryPoint= (UINT64) E1000UndiApiEntry;
> +  PxePtr->EntryPoint= (UINT64)(UINTN)E1000UndiApiEntry;
>PxePtr->reserved2[0]  = 0;
>PxePtr->reserved2[1]  = 0;
>PxePtr->reserved2[2]  = 0;
> @@ -842,7 +842,7 @@ InitNiiProtocol (
>  return EFI_INVALID_PARAMETER;
>}
>  
> -  NiiProtocol31->Id = (UINT64) (mE1000Pxe31);
> +  NiiProtocol31->Id = (UINT64)(UINTN)mE1000Pxe31;
>NiiProtocol31->IfNum  = mE1000Pxe31->IFcnt;
>  
>NiiProtocol31->Revision   =
> EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL_REVISION_31;
> @@ -938,7 +938,7 @@ InitUndiCallbackFunctions (
>NicInfo->MapMem  = (VOID *) 0;
>NicInfo->UnMapMem= (VOID *) 0;
>NicInfo->SyncMem = (VOID *) 0;
> -  NicInfo->UniqueId= (UINT64) NicInfo;
> +  NicInfo->UniqueId= (UINT64)(UINTN)NicInfo;
>NicInfo->VersionFla

Re: [edk2] [PATCH edk2-staging 05/19] IntelUndiPkg/GigUndiDxe: move BRAND_STRUCT declaration after type definition

2019-01-29 Thread Ryszard Knop
Hmm, BRAND_STRUCT_S could be simplified into a single struct def -
works on both MSVC and GCC.

Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Move the extern declaration of mBrandingTable[] after the definition
> of
> the type. This solves a build issue with GCC.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> index e156b587f6a7..e2b730131f8e 100644
> --- a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> +++ b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> @@ -33,9 +33,6 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
>  typedef struct BRAND_STRUCT_S BRAND_STRUCT;
>  
> -extern BRAND_STRUCT mBrandingTable[];
> -extern UINTNmBrandingTableSize;
> -
>  /* Defines */
>  #define INVALID_VENDOR_ID 0x
>  #define INVALID_SUBVENDOR_ID  0x
> @@ -53,6 +50,9 @@ struct BRAND_STRUCT_S {
>CHAR16 *BrandString;
>  };
>  
> +extern BRAND_STRUCT mBrandingTable[];
> +extern UINTNmBrandingTableSize;
> +
>  /* Function declarations */
>  
>  /** Returns pointer to current device's branding string (looks for
> best match)

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 04/19] IntelUndiPkg/GigUndiDxe: consistently use forward slashes as path separators

2019-01-29 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Replace backslashes in paths with forward slashes to be compatible
> with
> non-Windows OSes.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/Decode.c   |  2 +-
>  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf | 14 +++---
>  IntelUndiPkg/GigUndiDxe/e1000_osdep.h  |  4 ++--
>  3 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/Decode.c
> b/IntelUndiPkg/GigUndiDxe/Decode.c
> index 14060db0d050..9f8a5a8c1c81 100644
> --- a/IntelUndiPkg/GigUndiDxe/Decode.c
> +++ b/IntelUndiPkg/GigUndiDxe/Decode.c
> @@ -27,7 +27,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
>  
> ***/
>  #include "e1000.h"
> -#include 
> +#include 
>  
>  /** This routine determines the operational state of the UNDI.  It
> updates the state flags in the
> Command Descriptor Block based on information derived from the
> GigAdapter instance data.
> diff --git a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> index 0e4462733df6..6c195872c00f 100644
> --- a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> +++ b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> @@ -115,13 +115,13 @@ AdapterInformation.c
>  AdapterInformation.h
>  Version.h
>  
> -wol\wol.h
> -wol\wol.c
> -wol\wolimpl.h
> -wol\wolimpl.c
> -wol\wolfamily.c
> -wol\wolinfo.c
> -wol\wol_1G.c
> +wol/wol.h
> +wol/wol.c
> +wol/wolimpl.h
> +wol/wolimpl.c
> +wol/wolfamily.c
> +wol/wolinfo.c
> +wol/wol_1G.c
>  
>  [sources.X64]
>
> diff --git a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
> b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
> index 01c0843a2c9a..4408b409a445 100644
> --- a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
> +++ b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
> @@ -31,8 +31,8 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
>  #include 
>  #include 
> -#include 
> -#include 
> +#include 
> +#include 
>  
>  #pragma warning(disable : 4244)
>  #pragma warning(disable : 4206)

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 03/19] IntelUndiPkg/GigUndiDxe: consistently use lowercase for e1000 in filenames

2019-01-29 Thread Ryszard Knop
Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Rename E1000.[ch] and E1000_osdep.[ch] to all lowercase, and replace
> all #include references with lowercase ones as well.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.c | 2 +-
>  IntelUndiPkg/GigUndiDxe/ComponentName.c  | 2 +-
>  IntelUndiPkg/GigUndiDxe/Decode.c | 2 +-
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.h  | 2 +-
>  IntelUndiPkg/GigUndiDxe/Dma.c| 2 +-
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c| 2 +-
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c  | 2 +-
>  IntelUndiPkg/GigUndiDxe/DriverHealth.c   | 2 +-
>  IntelUndiPkg/GigUndiDxe/EepromConfig.h   | 2 +-
>  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf   | 8 ---
> -
>  IntelUndiPkg/GigUndiDxe/Init.c   | 2 +-
>  IntelUndiPkg/GigUndiDxe/StartStop.c  | 2 +-
>  IntelUndiPkg/GigUndiDxe/StartStop.h  | 2 +-
>  IntelUndiPkg/GigUndiDxe/{E1000.c => e1000.c} | 2 +-
>  IntelUndiPkg/GigUndiDxe/{E1000.h => e1000.h} | 0
>  IntelUndiPkg/GigUndiDxe/{E1000_osdep.c => e1000_osdep.c} | 2 +-
>  IntelUndiPkg/GigUndiDxe/{E1000_osdep.h => e1000_osdep.h} | 0
>  IntelUndiPkg/GigUndiDxe/wol/wolimpl.h| 2 +-
>  18 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> index b0320b11839b..8918c538e447 100644
> --- a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> +++ b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> @@ -28,7 +28,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
> ***/
>  #include "Uefi.h"
>  
> -#include "E1000.h"
> +#include "e1000.h"
>  
>  
>  #include "AdapterInformation.h"
> diff --git a/IntelUndiPkg/GigUndiDxe/ComponentName.c
> b/IntelUndiPkg/GigUndiDxe/ComponentName.c
> index 1473bfbed0af..70baf00f4a5d 100644
> --- a/IntelUndiPkg/GigUndiDxe/ComponentName.c
> +++ b/IntelUndiPkg/GigUndiDxe/ComponentName.c
> @@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
> IN ANY WAY OUT OF THE USE
>  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  
>  
> ***/
> -#include "E1000.h"
> +#include "e1000.h"
>  
>  #include "ComponentName.h"
>  #include "DeviceSupport.h"
> diff --git a/IntelUndiPkg/GigUndiDxe/Decode.c
> b/IntelUndiPkg/GigUndiDxe/Decode.c
> index 88e8be315bd1..14060db0d050 100644
> --- a/IntelUndiPkg/GigUndiDxe/Decode.c
> +++ b/IntelUndiPkg/GigUndiDxe/Decode.c
> @@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
> IN ANY WAY OUT OF THE USE
>  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  
>  
> ***/
> -#include "E1000.h"
> +#include "e1000.h"
>  #include 
>  
>  /** This routine determines the operational state of the UNDI.  It
> updates the state flags in the
> diff --git a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> index f309044d9b9d..e156b587f6a7 100644
> --- a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> +++ b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> @@ -29,7 +29,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  #ifndef DEVICE_SUPPORT_H_
>  #define DEVICE_SUPPORT_H_
>  
> -#include "E1000.h"
> +#include "e1000.h"
>  
>  typedef struct BRAND_STRUCT_S BRAND_STRUCT;
>  
> diff --git a/IntelUndiPkg/GigUndiDxe/Dma.c
> b/IntelUndiPkg/GigUndiDxe/Dma.c
> index 76a3fcf69601..bf94c1e2fd54 100644
> --- a/IntelUndiPkg/GigUndiDxe/Dma.c
> +++ b/IntelUndiPkg/GigUndiDxe/Dma.c
> @@ -27,7 +27,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
>  
> ***/
>  
> -#include "E1000.h"
> +#include "e1000.h"
>  
>  #include "Dma.h"
>  
> diff --git a/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
> b/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
> index 118c1b2b9b04..20d40ab672ef 100644
> --- a/IntelUndiPkg/GigUndiDxe/DriverConfigura

Re: [edk2] [PATCH edk2-staging 02/19] IntelUndiPkg: remove EOF markers

2019-01-29 Thread Ryszard Knop
This seems to be an issue within our open source tree generation script
which appends some nasty unexpected characters... MSVC didn't ever
complain about these. Fixed this, next commits should be clean.

Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Remove the Ctrl-Z markers at the end of each file: these break the
> GCC build on Linux.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  | 1 -
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.h  | 1 -
>  IntelUndiPkg/GigUndiDxe/Brand.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/ComponentName.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/ComponentName.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/Decode.c  | 1 -
>  IntelUndiPkg/GigUndiDxe/Decode.h  | 1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/Dma.c | 1 -
>  IntelUndiPkg/GigUndiDxe/Dma.h | 1 -
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c | 1 -
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.h | 1 -
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/DriverHealth.c| 1 -
>  IntelUndiPkg/GigUndiDxe/E1000.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/E1000.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/E1000_osdep.c | 1 -
>  IntelUndiPkg/GigUndiDxe/E1000_osdep.h | 1 -
>  IntelUndiPkg/GigUndiDxe/EepromConfig.c| 1 -
>  IntelUndiPkg/GigUndiDxe/EepromConfig.h| 1 -
>  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 1 -
>  IntelUndiPkg/GigUndiDxe/Hii.c | 1 -
>  IntelUndiPkg/GigUndiDxe/Hii.h | 1 -
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.c  | 1 -
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.h  | 1 -
>  IntelUndiPkg/GigUndiDxe/Init.c| 1 -
>  IntelUndiPkg/GigUndiDxe/Init.h| 1 -
>  IntelUndiPkg/GigUndiDxe/Inventory.vfr | 1 -
>  IntelUndiPkg/GigUndiDxe/NVDataStruc.h | 1 -
>  IntelUndiPkg/GigUndiDxe/StartStop.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/StartStop.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/Version.h | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.c | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.h | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.c | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.h | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_defines.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_hw.h| 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_i210.c  | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_i210.h  | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_mac.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_mac.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_manage.c| 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_manage.h| 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_nvm.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_nvm.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_phy.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_phy.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_regs.h  | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wol.c | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wol.h | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wol_1G.c  | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wolfamily.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wolimpl.c | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wolimpl.h | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wolinfo.c | 1 -
>  IntelUndiPkg/I40eUndiDxe/AdapterInformation.c | 1 -
>  IntelUndiPkg/I40eUndiDxe/AdapterInformation.h | 1 -
>  IntelUndiPkg/I40eUndiDxe/Brand.c  | 1 -
>  IntelUndiPkg/I40eUndiDxe/ComponentName.c  | 1 -
>  IntelUndiPkg/I40eUndiDxe/ComponentName.h  | 1 -
>  IntelUndiPkg/I40eUndiDxe/Decode.c | 1 -
>  IntelUndiPkg/I40eUndiDxe/Decode.h | 1 -
>  IntelUndiPkg/I40eUndiDxe/DeviceSupport.c  | 1 -
>  IntelUndiPkg/I40eUndiDxe/DeviceSupport.h  | 1 -
>  IntelUndiPkg/I40eUndiDxe/Dma.c| 1 -
>  IntelUndiPkg/I40eUndiDxe/Dma.h| 1 -
>  IntelUndiPkg/I40eUndiDxe/DriverDiagnostics.c  | 1 -
>  IntelUndiPkg/I40eUndiDxe/DriverDiagnostics.h  | 1 -
>  IntelUndiPkg/I40e

Re: [edk2] [PATCH edk2-staging 00/19] IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC

2019-01-29 Thread Ryszard Knop
+Team

On Tue, 2019-01-29 at 14:13 +0100, Ryszard Knop wrote:
> Hi Ard,
> 
> I've finally got some time to review and merge all of this. A bit
> problematic thing is that we internally have a separate tree that we
> need to merge those commits into, then generate the open source tree
> and related commits from that. This will result in somewhat broken
> history, so sorry about that in advance - we're still figuring out
> the
> proper way to handle multiple source trees on our end without messing
> it up. I'll push these changes to edk2-staging once we've got it all
> ready.
> 
> On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> > This series fixes the GigUndiDxe in the edk2-staging/Intel_UNDI
> > branch
> > at github.com/tianocore so it can be built with GCC on Linux for
> > ARM
> > and AARCH64 (as well as X64)
> > 
> > Ard Biesheuvel (19):
> >   IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to supported
> > architectures
> >   IntelUndiPkg: remove EOF markers
> >   IntelUndiPkg/GigUndiDxe: consistently use lowercase for e1000 in
> > filenames
> >   IntelUndiPkg/GigUndiDxe: consistently use forward slashes as path
> > separators
> >   IntelUndiPkg/GigUndiDxe: move BRAND_STRUCT declaration after type
> > definition
> >   IntelUndiPkg/GigUndiDxe: use intermediate UINTN casts for
> > pointers
> >   IntelUndiPkg/GigUndiDxe: create GCC alternatives for MSFT build
> > options
> >   IntelUndiPkg/GigUndiDxe: add missing VOID** cast
> >   IntelUndiPkg/GigUndiDxe: add missing UINT8* cast
> >   IntelUndiPkg/GigUndiDxe: add missing braces to GUID literals
> >   IntelUndiPkg/GigUndiDxe: fix incorrect use of CPP token pasting
> >   IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to correct
> > pointer
> > type
> >   IntelUndiPkg/GigUndiDxe: don't take address of cast expression
> >   IntelUndiPkg/GigUndiDxe: redefine UNREFERENCED_nPARAMETER macros
> > for
> > GCC
> >   IntelUndiPkg/GigUndiDxe: remove forward declaration of non-
> > existent
> > function
> >   IntelUndiPkg/GigUndiDxe: fix incorrect indentation
> >   IntelUndiPkg/GigUndiDxe: move MSFT warning overrides to INF file
> >   IntelUndiPkg/GigUndiDxe: add missing EFIAPI modifiers
> >   IntelUndiPkg/GigUndiDxe: remove or reorganize unused variables
> > 
> >  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  |  6 ++-
> >  IntelUndiPkg/GigUndiDxe/AdapterInformation.h  |  1 -
> >  IntelUndiPkg/GigUndiDxe/Brand.c   |  1 -
> >  IntelUndiPkg/GigUndiDxe/ComponentName.c   |  5 ++-
> >  IntelUndiPkg/GigUndiDxe/ComponentName.h   |  2 +-
> >  IntelUndiPkg/GigUndiDxe/Decode.c  |  5 +--
> >  IntelUndiPkg/GigUndiDxe/Decode.h  |  1 -
> >  IntelUndiPkg/GigUndiDxe/DeviceSupport.c   |  1 -
> >  IntelUndiPkg/GigUndiDxe/DeviceSupport.h   |  9 ++---
> >  IntelUndiPkg/GigUndiDxe/Dma.c | 11 +++---
> >  IntelUndiPkg/GigUndiDxe/Dma.h |  1 -
> >  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c |  6 ++-
> >  IntelUndiPkg/GigUndiDxe/DriverConfiguration.h |  1 -
> >  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 12 +++---
> >  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h   |  1 -
> >  IntelUndiPkg/GigUndiDxe/DriverHealth.c|  5 ++-
> >  IntelUndiPkg/GigUndiDxe/EepromConfig.c|  1 -
> >  IntelUndiPkg/GigUndiDxe/EepromConfig.h|  3 +-
> >  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 39 +--
> > 
> >  IntelUndiPkg/GigUndiDxe/Hii.c | 11 +++---
> >  IntelUndiPkg/GigUndiDxe/Hii.h |  1 -
> >  IntelUndiPkg/GigUndiDxe/HiiInternalLib.c  |  3 --
> >  IntelUndiPkg/GigUndiDxe/HiiInternalLib.h  |  1 -
> >  IntelUndiPkg/GigUndiDxe/Init.c| 11 +++---
> >  IntelUndiPkg/GigUndiDxe/Init.h|  1 -
> >  IntelUndiPkg/GigUndiDxe/Inventory.vfr |  1 -
> >  IntelUndiPkg/GigUndiDxe/NVDataStruc.h |  7 ++--
> >  IntelUndiPkg/GigUndiDxe/StartStop.c   |  5 ++-
> >  IntelUndiPkg/GigUndiDxe/StartStop.h   |  7 ++--
> >  IntelUndiPkg/GigUndiDxe/Version.h |  1 -
> >  IntelUndiPkg/GigUndiDxe/{E1000.c => e1000.c}  | 37 ---
> > --
> > -
> >  IntelUndiPkg/GigUndiDxe/{E1000.h => e1000.h}  |  5 +--
> >  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.c   |  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.h   |  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_82571.c |  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_82571.h |  1 -
> > 

Re: [edk2] [PATCH edk2-staging 01/19] IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to supported architectures

2019-01-29 Thread Ryszard Knop
One thing of note here: We're primarily using MSVC for IA32/X64 builds,
and that's the only thing we "officially" support. I'll try to build
and test GCC binaries once in a while as well, but things might break
once now and then. Our team also doesn't have any ARM hardware to test
this on, so I'd appreciate any reports if it breaks :)

Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/IntelOpenSourceUndiPkg.dsc | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
> b/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
> index 21b1fb27984e..ca440bde2cb4 100644
> --- a/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
> +++ b/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
> @@ -29,7 +29,7 @@
>PLATFORM_VERSION   = 0.1
>DSC_SPECIFICATION  = 0x00010005
>OUTPUT_DIRECTORY   = Build/IntelUndiPkg
> -  SUPPORTED_ARCHITECTURES= IA32|IPF|X64
> +  SUPPORTED_ARCHITECTURES= IA32|IPF|X64|ARM|AARCH64
>BUILD_TARGETS  = DEBUG|RELEASE|DEV
>SKUID_IDENTIFIER   = DEFAULT
>  
> @@ -62,6 +62,17 @@
>SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynch
> ronizationLib.inf
>DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib
> /BaseDebugPrintErrorLevelLib.inf
>  
> +[LibraryClasses.ARM, LibraryClasses.AARCH64]
> +  #
> +  # It is not possible to prevent the ARM compiler from inserting
> calls to
> +  # intrinsic functions. This library provides the instrinsic
> functions such
> +  # a compiler may generate calls to.
> +  #
> +  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.in
> f
> +
> +  # Add support for GCC stack protector
> +  NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
> +
>  
> 
>  #
>  # Pcd Section - list of all EDK II PCD Entries defined by this
> Platform

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-staging 00/19] IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC

2019-01-29 Thread Ryszard Knop
Hi Ard,

I've finally got some time to review and merge all of this. A bit
problematic thing is that we internally have a separate tree that we
need to merge those commits into, then generate the open source tree
and related commits from that. This will result in somewhat broken
history, so sorry about that in advance - we're still figuring out the
proper way to handle multiple source trees on our end without messing
it up. I'll push these changes to edk2-staging once we've got it all
ready.

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> This series fixes the GigUndiDxe in the edk2-staging/Intel_UNDI
> branch
> at github.com/tianocore so it can be built with GCC on Linux for ARM
> and AARCH64 (as well as X64)
> 
> Ard Biesheuvel (19):
>   IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to supported
> architectures
>   IntelUndiPkg: remove EOF markers
>   IntelUndiPkg/GigUndiDxe: consistently use lowercase for e1000 in
> filenames
>   IntelUndiPkg/GigUndiDxe: consistently use forward slashes as path
> separators
>   IntelUndiPkg/GigUndiDxe: move BRAND_STRUCT declaration after type
> definition
>   IntelUndiPkg/GigUndiDxe: use intermediate UINTN casts for pointers
>   IntelUndiPkg/GigUndiDxe: create GCC alternatives for MSFT build
> options
>   IntelUndiPkg/GigUndiDxe: add missing VOID** cast
>   IntelUndiPkg/GigUndiDxe: add missing UINT8* cast
>   IntelUndiPkg/GigUndiDxe: add missing braces to GUID literals
>   IntelUndiPkg/GigUndiDxe: fix incorrect use of CPP token pasting
>   IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to correct
> pointer
> type
>   IntelUndiPkg/GigUndiDxe: don't take address of cast expression
>   IntelUndiPkg/GigUndiDxe: redefine UNREFERENCED_nPARAMETER macros
> for
> GCC
>   IntelUndiPkg/GigUndiDxe: remove forward declaration of non-existent
> function
>   IntelUndiPkg/GigUndiDxe: fix incorrect indentation
>   IntelUndiPkg/GigUndiDxe: move MSFT warning overrides to INF file
>   IntelUndiPkg/GigUndiDxe: add missing EFIAPI modifiers
>   IntelUndiPkg/GigUndiDxe: remove or reorganize unused variables
> 
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  |  6 ++-
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/Brand.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/ComponentName.c   |  5 ++-
>  IntelUndiPkg/GigUndiDxe/ComponentName.h   |  2 +-
>  IntelUndiPkg/GigUndiDxe/Decode.c  |  5 +--
>  IntelUndiPkg/GigUndiDxe/Decode.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.h   |  9 ++---
>  IntelUndiPkg/GigUndiDxe/Dma.c | 11 +++---
>  IntelUndiPkg/GigUndiDxe/Dma.h |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c |  6 ++-
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.h |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 12 +++---
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverHealth.c|  5 ++-
>  IntelUndiPkg/GigUndiDxe/EepromConfig.c|  1 -
>  IntelUndiPkg/GigUndiDxe/EepromConfig.h|  3 +-
>  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 39 +--
> 
>  IntelUndiPkg/GigUndiDxe/Hii.c | 11 +++---
>  IntelUndiPkg/GigUndiDxe/Hii.h |  1 -
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.c  |  3 --
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/Init.c| 11 +++---
>  IntelUndiPkg/GigUndiDxe/Init.h|  1 -
>  IntelUndiPkg/GigUndiDxe/Inventory.vfr |  1 -
>  IntelUndiPkg/GigUndiDxe/NVDataStruc.h |  7 ++--
>  IntelUndiPkg/GigUndiDxe/StartStop.c   |  5 ++-
>  IntelUndiPkg/GigUndiDxe/StartStop.h   |  7 ++--
>  IntelUndiPkg/GigUndiDxe/Version.h |  1 -
>  IntelUndiPkg/GigUndiDxe/{E1000.c => e1000.c}  | 37 -
> -
>  IntelUndiPkg/GigUndiDxe/{E1000.h => e1000.h}  |  5 +--
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.c |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.h |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.c |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.h |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_defines.h   | 10 -
>  IntelUndiPkg/GigUndiDxe/e1000_hw.h|  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_i210.c  |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_i210.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c   | 18 -
>  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_mac.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_mac.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_manage.c|  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_manage.h