From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by mx.groups.io with SMTP id smtpd.web12.51648.1585579194777736847 for ; Mon, 30 Mar 2020 07:39:55 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@akeo-ie.20150623.gappssmtp.com header.s=20150623 header.b=bo8VbGmJ; spf=none, err=permanent DNS error (domain: akeo.ie, ip: 209.85.128.65, mailfrom: pete@akeo.ie) Received: by mail-wm1-f65.google.com with SMTP id c187so20248987wme.1 for ; Mon, 30 Mar 2020 07:39:54 -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=iAdItAaAGZEkW934BLSQFvLX6GYEz1xtF69Mh9VyL4E=; b=bo8VbGmJXO0ayMgcwT7d3EN8K/uMAFSFo0pa+5dKbWYSdzYXMo+S1oUeHb/Gr2PFN0 DyJFLq+lx+6g9uCDAu5C3xJN/A2pcSIcBMWAClotOn6/Kd7DFrsUpqROpXnuoZ1QodCy SrKq5nl5iSdooIzbPyeX9/oCofDejMLFMZz5XhJY5R9qSgAUKPGjY0EX8Id15IUsQ/Kk 1BPp0TlHLKPgtqxBuTDTikTF4CccqXeqxb3RvfGT+QfX1KeohRFPURH9zRgOw35k9N8+ rOO0ZUscGWL6yvIQ1JhNDrR3kJEzDgn06S0IrtX4/FQey/eNxbN1lEa9BnckC4R/UuVh N2xA== 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=iAdItAaAGZEkW934BLSQFvLX6GYEz1xtF69Mh9VyL4E=; b=qX2UuJC/vvN3deyYGYDwn5++PhvYGoJilm98SlPptIQKMn12Mph2IBPC6lsTQNotUa 2jMtbNGgPNF4lHqtBXggTctXn6jNflxDj1dEBOn6BfOnmSSKU6e7VszFQ8F428HsRd7k 4xa+zOTZTgRw/Q2fC72d9za64iGdYzIW197ldqdlwyMeSru8chepiXppVTRGMcMGw0xx TuFRpAND4mj2JxoLnz4VfjL7BtBEEtO3af6MgzZpjwDmEdqH6sRx5sAsVJc1pusKmHki 1xPWFtw7iPyO5F9Z98Tfqs5y/64K2E3c6pGk0cKEeBCrdC39VOUuJ7h4oH5e25fC8eBh A5CA== X-Gm-Message-State: ANhLgQ2cv7GsB1PtD2u3sErcDjOqDzWka5Kz/Zodp/nV4UuDrB3o8pvI cMXArIULzPM6gENBL5aX7HOc0A== X-Google-Smtp-Source: ADFU+vvyL8A2vRqAohchEsI8qPPbupjOaA+ZBCYm0fNMF8go6wohcfBXy/2VUCBFwiMQa8VyZGkKCQ== X-Received: by 2002:a1c:8008:: with SMTP id b8mr13021885wmd.43.1585579193292; Mon, 30 Mar 2020 07:39:53 -0700 (PDT) Return-Path: Received: from [10.0.0.122] ([84.203.45.232]) by smtp.googlemail.com with ESMTPSA id b199sm18367904wme.23.2020.03.30.07.39.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Mar 2020 07:39:52 -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> <20ba12ef-ae50-d40e-cc98-14482aafa486@akeo.ie> From: "Pete Batard" Message-ID: <413d1143-a4da-198a-841e-a4e96c3fd63e@akeo.ie> Date: Mon, 30 Mar 2020 15:39:51 +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:34, Ard Biesheuvel wrote: > On Mon, 30 Mar 2020 at 16:29, Pete Batard wrote: >> >> On 2020.03.30 15:16, Ard Biesheuvel wrote: >>> 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 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. >>>> >>> >>> 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 >> >> Then we have two very different visions for the platform, especially >> when it comes to the Pi 4, where networking and SD card support is >> pretty much NO_GO for any "older" OS (and troublesome enough as it is in >> modern nones). >> >> This is actually the one place where I'd like to see an actual use-case >> made for "older OSes incompatibility", especially when it comes to 6.0 >> MADT vs 6.3 MADT, where the only different is that 6.0 had 3 reserved >> fields and 6.3 started to use 2 of those. >> >> For the record, the MADT blobs we got from Microsoft (for the Pi 3) were >> 6.0, and we did downgrade them to 5.1 for convenience (rather than >> compatibility issues), so I really fail to see the issue with bumping >> MADT to 6.3. >> >> Instead, what I'm seeing is folks who need the SPE fields for their >> platform and look at other implementations to see how to set them up >> wasting time having to send a duplicate of the current to edk2 for very >> dubious reasons. >> >>> I disagree. We add what we need when we need it. The patch volume is >>> high enough as it is. >> >> Well, considering that different folks will have to send duplicate >> patches, this doesn't entirely come as a surprise... >> >> Sorry, but I really can't see any good reason for this patch to be shot >> down. You guys *will* have to process a similar patch sooner or later. >> > > Again, I am happy to merge this patch. The argument is about whether > we need to upgrade RPi4 to 6.3 > Last time I checked, quite a few of the people who contributed code to the platform were of the opinion that we did. I will re-send an e-mail to the group, off-list, so that you get an idea of what the current stance is on that topic, and then decide whether your want to uphold your current position. Regards, /Pete