From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by mx.groups.io with SMTP id smtpd.web12.50695.1585576902988252223 for ; Mon, 30 Mar 2020 07:01:43 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=WNIwyPzO; spf=pass (domain: linaro.org, ip: 209.85.221.66, mailfrom: ard.biesheuvel@linaro.org) Received: by mail-wr1-f66.google.com with SMTP id 31so21760264wrs.3 for ; Mon, 30 Mar 2020 07:01:42 -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=+qZQZh/xpNxvPhGyLqB0IzfD4zwifx8msO8q/iwXIfY=; b=WNIwyPzOPvwpC00VY2xYOSAiYtwQs0UxZDL42lbdayblEIpvx9mPtEkmCgmBOwfvNH gAFlJMdjHX0DoDyUay+JoaVbJXbKQ91nhrRhfWkqpa0WdayEGgHs7W5TTFFBcOFFKsxi kz1sVP/gt79moLkIV99kyGCq4MV1C45Ylblqc5Ij7pJ6YEVzZY9JABvufYvRp1IL1qIx ZVHWfGbdzrwvPuw6F5FQq+VXiWm18nT4rkLsnGhOVN4D+a/1vrhQWCaXSEUil6hwob2k Sp4o7f2urTPaw1CF/Zu64PFl8pmh5iQ/+Yw83ZuXAC/a4wyXYbCJdLiGiuzFM3Jj+qvS brPQ== 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=+qZQZh/xpNxvPhGyLqB0IzfD4zwifx8msO8q/iwXIfY=; b=GSlptIAcUscocWar9VPwzR8Tm5Prw09yi/Dt8+CnZYPjDe1YZdWxlEJ5F9JKdQ5IeG ie2MhAYJFxUE8L7WJNAKBXfc9kTY2Y6UuZpqvRoNxOdNIBS77A9TqlFUxR5oPMIb+KTQ 3EU5qTToFeMqJ5vumlM8jAqSa/iZRbO75k06nMt3nR6gfCtvC1OQeEMK7IahJPP9Yx+e c8zrW5AVsSm5mAsXDFi7vjtKLqcKwlfy/hufATQA61pz4y1VyGfDBl00f+vTxpL/MhJo TBMEYXozL4gszGSsdK62YDlh/R4nPpHKUZo/2bw9II86vqCk+ItmElPRZxry0JkPxg/f hM2g== X-Gm-Message-State: ANhLgQ1e2daQyR1bBVq1RzCRseJWBBe9681LMkZPAK86CPOhDJkZD+9I mhfKg6xB+SpsdQ7zeFjEeB2eUy9TK+05Z8Qn6P0oFF9DVoo= X-Google-Smtp-Source: ADFU+vuGzdzcs1U3uZKq1B0ajwhNrngXdHgcwh29nPSm8vl44by7TUmJIrS1ju3j/vsTAQJfSldAGZTuJyeUyMIG6YY= X-Received: by 2002:a5d:4fcf:: with SMTP id h15mr14982053wrw.262.1585576901421; Mon, 30 Mar 2020 07:01:41 -0700 (PDT) MIME-Version: 1.0 References: <20200327130117.11304-1-pete@akeo.ie> <6fb85ee0-1894-8a6b-73d0-2a7adc0799ab@akeo.ie> In-Reply-To: <6fb85ee0-1894-8a6b-73d0-2a7adc0799ab@akeo.ie> From: "Ard Biesheuvel" Date: Mon, 30 Mar 2020 16:01:30 +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 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 subject = 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 AC= PI > >>> 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 that > >> complies with 6.3. > > This is what happens if you try to use EFI_ACPI_6_0_GICC_STRUCTURE_INIT > 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? > The only reason I'm sending an EDK2 patch, which I'd always rather avoid > 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. > >> Or is there another reason you want to update the > >> MADT to 6.3? > > I just want to fix the compilation error, as well as make sure that > folks who need the ACPI 6.3 SPE init can get it without having to spend > time waiting for an EDK2 patch to be applied. > > > BTW, this patch sets the size of the GICC entry to 'sizeof > > (EFI_ACPI_6_0_GIC_STRUCTURE)' so it is likely that the parser will > > choke on it. > > The structure size hasn't changed. There were 3 reserved bytes, and now > there's one reserve byte and one 16-bit word for the SPE. > > Since I actually need this patch as part of a platform update, I did > validate compilation, so, no, the parser doesn't choke on it. > I didn't mean to imply that you are being sloppy. I'd just like to understand what the point is of all of this, given that ACPI 6.3 is not needed to describe the RPi4