From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by mx.groups.io with SMTP id smtpd.web11.50643.1585577221724099640 for ; Mon, 30 Mar 2020 07:07:02 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@akeo-ie.20150623.gappssmtp.com header.s=20150623 header.b=OQ0851Gd; spf=none, err=permanent DNS error (domain: akeo.ie, ip: 209.85.221.67, mailfrom: pete@akeo.ie) Received: by mail-wr1-f67.google.com with SMTP id h15so21770957wrx.9 for ; Mon, 30 Mar 2020 07:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akeo-ie.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BQadT0KiP3s/pLTv0cmj5it33EDabRHf7/QMl0vdpNk=; b=OQ0851GdJtvtwORIBB9Wfq80JB/J8Vuv5zWIyyVuFMEegUBLVhIb/5xWF/LJefi4ty ebCmNzPG+IgSNn8GPLp8qZwL7/e/vIUmvoPkbuCahYJ4QEy7K43o268gODbmojlz0BCI Dn8duaiJU2T4JqzunVPK47FGMqspMjnPky7t/2TpQz8lCiZVlBdyl39GYvxAylYqtPab 21ar36r+1BhmT6f51oYdhE1BhENmQ+gApA+y0+dAj5t0MT+HqZV5UA10y1pyuyy92SCn HETFT6AE/qvRDyZgxYzOyWU93VpdjlD6SyWTC8YyiM0e6ZJupUnZKr31XlN4aLpjh45A gvwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BQadT0KiP3s/pLTv0cmj5it33EDabRHf7/QMl0vdpNk=; b=CyyOgBunZ6kd3X42Gk7PviGAzPGgCqspAl1a+jMTGAF4g3vLJ+1BYqzM9HdxMX0dzp UI5mpgm7kmJBhnSiskVhXnC+U7RwG+PT0L5lwkjcYEN0cYopCSOJtuG6RvH9zWIe5nCp HdewKmMdkn+JxJArMKtmtqQorEjEdBl742NWIE1t8DUzbVbaGa/ImXzq12TPrITuhXpZ kbWvl2QBkE/FiyjZ45gVxnBj/RLcP7Wgn61ObpfMv83uWPcL/KVt/ZboGIIoZ9c6EAMK FSyJmSaKlnkIUw10Ds5OhelMkg0H2FR0WU6W2NpkEiHpQzlGdybb+bKf1HA5HgdGSk24 8Tvw== X-Gm-Message-State: ANhLgQ2sXX/b5VzwlYTbaqfd5jIqwMCAijhYAhptszhHD7b7hx6o2AEs Ra2ub0sOKcueOXeatNyTcFZXkQ== X-Google-Smtp-Source: ADFU+vuQ94c+infUQEszjoUVWJ/DxHERnL7KS3Jbhg956PezKlpd61l1JhiZICamawKgaW6k7mI2RQ== X-Received: by 2002:a5d:630e:: with SMTP id i14mr15198538wru.260.1585577220281; Mon, 30 Mar 2020 07:07:00 -0700 (PDT) Return-Path: Received: from [10.0.0.122] ([84.203.45.232]) by smtp.googlemail.com with ESMTPSA id j6sm23636596wrb.4.2020.03.30.07.06.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Mar 2020 07:06:59 -0700 (PDT) Subject: Re: [PATCH 1/1] EmbeddedPkg/AcpiLib: add GICC table init macro for ACPI 6.3 To: Ard Biesheuvel Cc: edk2-devel-groups-io , Leif Lindholm References: <20200327130117.11304-1-pete@akeo.ie> <6fb85ee0-1894-8a6b-73d0-2a7adc0799ab@akeo.ie> From: "Pete Batard" Message-ID: Date: Mon, 30 Mar 2020 15:06:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit 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 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 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 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 ‘EFI_ACPI_RESERVED_BYTE’ >> {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 ‘EFI_ACPI_6_0_GICC_STRUCTURE_INIT’ >> 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 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. 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. 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. Regards, /Pete > >>>> 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 >