From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by mx.groups.io with SMTP id smtpd.web11.50875.1585577789844775591 for ; Mon, 30 Mar 2020 07:16:30 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=fch/rV2l; spf=pass (domain: linaro.org, ip: 209.85.128.67, mailfrom: ard.biesheuvel@linaro.org) Received: by mail-wm1-f67.google.com with SMTP id g62so22146574wme.1 for ; Mon, 30 Mar 2020 07:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oytqfRdI7h5Hwu8vQCjreMWU6f1V9GVeqx+0sXVkyv0=; b=fch/rV2lcsYcLaEk7O3fJBlBam4SJeOehF4w7hJw3E4C/nhsX5GettiDF1dMCjO1Y0 xclbNeR1TwaJfq8p+16+F5uJ+CrjvINzMFqLZMBEb2iG0LvKSTwzbuaibYBWNn0ni6mY MKDWnulMOL70DfoiiK/KbhiRbF8zgULRaCyl18vlz16VN2f9EJAJnhdfxDcOUYnBez6U nO8GQG+wyMFBMDKbDaVScpM3VPBWmsF8SXl+owyFKwJAGCUVotltUfUNRT8DZ06HwwkC n9fe1DqnsHz9xeirbhr3/V/nI3e3hkLcofuVhQ33H6H6a3vYWutTuBnUeecaTuS7uLng 87gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oytqfRdI7h5Hwu8vQCjreMWU6f1V9GVeqx+0sXVkyv0=; b=LuJARKWw3tUJIwbCCmOY9ayBjQigjHTnFB41ylkN6qB528Ta29a8h0jGZnxMXqlIV9 j/nmYewpf334LKMFH+JTUoXP8bPohIlLYH4b2ahQbJtrS2MuWj7Wytsrgr2aCp1X4JRq FuGyyCIl2EpcPl2uXYplzo7KcfcITGbZ4qkf5eNW8WIqC7wClqc4th2HNnyUgLOGaAP8 2XdAQVsTFkU28rD63vq4vyNKK2C/6PMdasUITbOhrcWGnImk3tw7a1fsePydRHhasRq6 2zaYpSQCJTN5LZvR2rolLea+B6VmRMKPOJ8ISvo/UMEiM9KRFVvJ0xcQ3q2hF8zJGmFq z++w== X-Gm-Message-State: ANhLgQ3KeT5W+vWWEaYJjG4l1Q8yxtTV8qu3ZnVxjlCcsUd1jEnD/WO5 i33pJg4l0QNyEHS7t+M+OX+Ug3IRe4yOydXtF39aCg== X-Google-Smtp-Source: ADFU+vvUJtXuqlsRqddxXUgu3gvav+QXaAi07CR0cwJ47XugRnzgR9FOmXJKxzQco6R7cYU2d0xE/T2JgAUBs7+khMs= X-Received: by 2002:a1c:6285:: with SMTP id w127mr14041208wmb.133.1585577788306; Mon, 30 Mar 2020 07:16:28 -0700 (PDT) MIME-Version: 1.0 References: <20200327130117.11304-1-pete@akeo.ie> <6fb85ee0-1894-8a6b-73d0-2a7adc0799ab@akeo.ie> In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 30 Mar 2020 16:16:17 +0200 Message-ID: Subject: Re: [PATCH 1/1] EmbeddedPkg/AcpiLib: add GICC table init macro for ACPI 6.3 To: Pete Batard Cc: edk2-devel-groups-io , Leif Lindholm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 30 Mar 2020 at 16:07, Pete Batard wrote: > > On 2020.03.30 15:01, Ard Biesheuvel wrote: > > On Mon, 30 Mar 2020 at 15:56, Pete Batard wrote: > >> > >> On 2020.03.30 14:20, Ard Biesheuvel wrote: > >>> On Mon, 30 Mar 2020 at 15:12, Ard Biesheuvel wrote: > >>>> > >>>> On Mon, 30 Mar 2020 at 15:09, Pete Batard wrote: > >>>>> > >>>>> On 2020.03.30 14:06, Ard Biesheuvel wrote: > >>>>>> On Fri, 27 Mar 2020 at 14:06, Pete Batard wrote: > >>>>>>> > >>>>>>> Incidentally, this is not an [edk2-platform] patch, as the subjec= t line > >>>>>>> from previous mail seemed to indicate, but an [edk2] patch. > >>>>>>> > >>>>>> > >>>>>> Do we have a user for this? > >>>>> > >>>>> Yes we do. I have a pachset lined up that updates the Raspberry Pi = ACPI > >>>>> to 6.3, that has a dependency on this. > >>>>> > >>>> > >>>> But does the RPi have SPE and the associated overflow interrupt? > >> > >> No, but it doesn't matter since the specs indicate that SPE values can > >> be set to zero if unused/non-applicable. > >> > >>>> ACPI > >>>> is designed to be backward compatible, so it is perfectly acceptable > >>>> to use the 6.2 macros in the context of a firmware implementation th= at > >>>> complies with 6.3. > >> > >> This is what happens if you try to use EFI_ACPI_6_0_GICC_STRUCTURE_INI= T > >> in a 6.3 context: > >> > >> /usr/src/edk2/MdePkg/Include/IndustryStandard/Acpi10.h:297:33: error: > >> excess elements in scalar initializer [-Werror] > >> #define EFI_ACPI_RESERVED_BYTE 0x00 > >> ^~~~ > >> Building ... > >> /usr/src/edk2/MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf [AARCH64] > >> /usr/src/edk2/EmbeddedPkg/Include/Library/AcpiLib.h:64:30: note: in > >> expansion of macro =E2=80=98EFI_ACPI_RESERVED_BYTE=E2=80=99 > >> {EFI_ACPI_RESERVED_BYTE, EFI_ACPI_RESERVED_BYTE, > >> EFI_ACPI_RESERVED_BYTE} \ > >> ^~~~~~~~~~~~~~~~~~~~~~ > >> /usr/src/edk2-platforms/Platform/RaspberryPi/AcpiTables/Madt.aslc:64:5= : > >> note: in expansion of macro =E2=80=98EFI_ACPI_6_0_GICC_STRUCTURE_INIT= =E2=80=99 > >> EFI_ACPI_6_0_GICC_STRUCTURE_INIT ( > >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> > > > > What do you mean exactly by 'in a 6.3 context': are you trying to > > statically initialize a 63 struct with the 60 macro? > > Yes. I am trying to upgrade all of our ACPI tables to 6.3, on account > that (part of a commit message from the edk2-platform I have lined up): > > ----------------------------------------------------------------------- > Because of its widespread availability and low price, we expect the > Raspberry Pi source to be used by platform developers as a starting > point to create their own platform implementation. > > As such, it makes a lot of sense to want to use the most up to date > underlying standards, even if the pay off is limited in this case, > as it may help others benefit from the latest improvements and > features brought by modern ACPI. > ----------------------------------------------------------------------- > > >> The only reason I'm sending an EDK2 patch, which I'd always rather avo= id > >> so that edk2-platforms patches can be applied faster, is that I haven'= t > >> been able to find a way to make the existing 6.0 macros work in a 6.3 > >> context, and I expect that this will be the case for others. > >> > > > > By why do we need the 6.3 context? If 6.0 can describe our platform > > fully, it is actually better for compatibility to stick with it rather > > than upgrade to 6.3. > > See above. > > I have to say that I'm a bit taken aback by the idea that, even though > we can anticipate that there will be a need for a 6.3 macro that does > initialise the SPE field, there seems to be strong reluctance to add > that macro before someone makes the case for it. > Well, the reason I asked was because I only want to merge changes that are actually need. If there is a valid need, I will happily merge this patch. But as it turns out, the reason is simply being able to claim that we implement the latest ACPI revision, which is actually a bad idea for platforms that don't actually rely on any of the new features, since it may prevent you from being able to run older OSes > Ideally, we should update our macros the minute the specs are released, > regardless of whether we believe there's a use-case for it or not. > I disagree. We add what we need when we need it. The patch volume is high enough as it is.