Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Message-ID: <41160dbf-d8c8-4dc0-9fda-42cc97df5b77@intel.com>
Date:   Mon, 20 Nov 2023 09:19:14 -0700
User-Agent: Betterbird (Linux)
Subject: Re: [PATCH] ACPI: acenv: Permit compilation from within the kernel
To:     "Rafael J. Wysocki" <rafael@kernel.org>,
        Sam Edwards <cfsworks@gmail.com>
CC:     Linus Walleij <linus.walleij@linaro.org>,
        Len Brown <lenb@kernel.org>,
        Robert Moore <robert.moore@intel.com>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Hanjun Guo <guohanjun@huawei.com>,
        Arnd Bergmann <arnd@arndb.de>,
        "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
        <linux-acpi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>
References: <20231114-arm-build-bug-v1-1-458745fe32a4@linaro.org>
 <b2354c21-3a1a-c446-fee0-db0c78d05c71@gmail.com>
 <CAJZ5v0idWdJq3JSqQWLG5q+b+b=zkEdWR55rGYEoxh7R6N8kFQ@mail.gmail.com>
Content-Language: en-US
From:   Dave Jiang <dave.jiang@intel.com>
In-Reply-To: <CAJZ5v0idWdJq3JSqQWLG5q+b+b=zkEdWR55rGYEoxh7R6N8kFQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ejVWUm1IMy9hZWw0a3ZxaGpVdzNLWHBrWWhxNTdCcElna2VtOVdaeG8vZnl0?=
 =?utf-8?B?RDlmL3FsYXZNemZiNHU3MmdKcSt2NUp3dkFNQXQrMkdSWE42WFpwYU1TZ09H?=
 =?utf-8?B?bkE1UVBvbW9hVkcwa1Y2alZWUllXUGIrTWZpVnRUMHpzVGNEWUUvTlJvZEhU?=
 =?utf-8?B?d3ZuVmpTUlRRbkZKZkwvU2dJM2x1blpXL01udWpMNjVaWElaOWdOUjdXTjh3?=
 =?utf-8?B?eGRCbGdmRXJLcHBDM2J1QWxLaklvUERUTHppSW5aZEk3Yk1ndXVjMEhWU2hL?=
 =?utf-8?B?Ukg4YkZQNER3Z0hYRlRQV0R3YkwwK09WZHVCdXdGMFNidldzT3dVVGdVNVpC?=
 =?utf-8?B?eVpTKzFaZ09ZdzJJTVZ4ZG81bmV6UHFnSVhlenc5amI5bllNRjhNYitLeHEz?=
 =?utf-8?B?VnVPcjNmbWxQcGxPZC9RM1dKUEE0NTNmK2lKOFNNOENpZnpDb1NPNnM5QlVE?=
 =?utf-8?B?amozcjBrNVAvTzlkRGp4ZjZHb21nSHI2ditvaTJHclYvelNleVo2TFBCUklP?=
 =?utf-8?B?U2hyemlLa3NyKy9IQ1VhdTRWRS9xd1lWSXpURG15Yy9mNXFEYVdkRHI1R056?=
 =?utf-8?B?MUpZajQ0VHRWZDVCYUF3dXA5WUp5SWU3YzhUYTVOQVVIcGVIblFKN1RmMkdE?=
 =?utf-8?B?dDNvcmtQaHorMkJXcjB2UmZJZjhpS3JaODFzbUdGT1FTQlJOY2tVeUlVaWxI?=
 =?utf-8?B?aG5jdFhVY0JxN3dyR3NqVTV5eVFVbnhZYVNBRTdzRlNFNEFsU3pCUVU4Vzdy?=
 =?utf-8?B?L2Vlbjk1M1BCVVRNMFMvM05UcGg3S0wrMU9ST0FoR3NtbHp2cDV3UEdteWp0?=
 =?utf-8?B?MXlKZkg5Z1BJSy9VQWlEeDNiT1Rxa296UG1qWXIzSzZKcnRGK24rWG8va05v?=
 =?utf-8?B?L2xzek45cmd0RzRtTm1TSFVNT3ZieTNzMmo2Z2YzbVRBZXFwZGI2dmdlLzNX?=
 =?utf-8?B?QlFHWFlienFnOEU3RXJBQXh5RmRCa3htbUpsdVNTY0FYbFRkcTRtVWJsSStY?=
 =?utf-8?B?cUdDTmNsSFhuZExlcmZKZ1RlMktYcUl6eGp0aGsrMDlQejFBQm5taU01dkV3?=
 =?utf-8?B?cVpRblY5U2FLQytnUVNPWUROT01ZRldsTVhpQm1hcGNIcFUycFRBYUlOOGU5?=
 =?utf-8?B?MG1aMDN2c0ljNTJMZVliWW9OMnVuclRoTk02VldpMnlxT2VNRXM3MHJ3TWk3?=
 =?utf-8?B?b0Excm93ZGRNOHlrbUkya2tsTy9BRU5YVW5jZ0JRSVR4ZGw2NzB1eURKVGRC?=
 =?utf-8?B?cDZtT2duY01aT0FjK3FMUk41cCtpVElOVlBQTGwycnYyV0wxRDZGWDQ3c3FM?=
 =?utf-8?B?WFRDWmpLSTZDb0M5d0ZyNVcrbmRsSVNVc25ZQTdEZkJodjVqa1l4WnlUR2Fa?=
 =?utf-8?B?TUE5V2tGbEt5RTkwU1Vhd2FyR21DdmlBR0tkcnJ4aldXYjBrei9rOWl4Q2ln?=
 =?utf-8?B?NW5Xd0VqNjVFaGlhYmtHOVZ3QVdSalc1Y2VDWm9kdDlGLzhCczdCWEg5VVdB?=
 =?utf-8?B?V3pzY2tpaXNEL1pQcFY3akt2dWI2UGxLZFJ2Lzd4L0htd2toWU5YY2tpS1Bu?=
 =?utf-8?B?bmVTQUFYQTZaRTdMbVZJOVY0cEFBRlJQeE43VmhEeFA4N1lCeGh3cEdQUnRS?=
 =?utf-8?B?YVdMTDRFNTZqbVdLZy9FSnRKOW1SN0xqbGhmaFgrWFl3N1BpWjNXTExPcWIr?=
 =?utf-8?B?UU9JdS9hR1JtMVBEaTlQRXFuSGk3a2pab1UyN3NkSG1GVTBrc1NWMmNpZWM1?=
 =?utf-8?B?ZG5jdlNndVMvUm9ta0lKS1M4QmVMYXI5WnNIcm85OEw2YkhIKzBMZDAreWtC?=
 =?utf-8?B?SWNJNjIxelBhRWJKVGdVd25SZndhM3ZBRnRGUG5CczZVaW1EdUorbzFHQlNH?=
 =?utf-8?B?UFBUc01hR3YxaWxYeU1zd2pjMzFXQUNYaDVVQ1gyUVoxcE0ySEVBNit1UjNW?=
 =?utf-8?B?RWpOZVpWNFprd3BiMzZobERyZlNlNFpwK0tkb1RpTWRSOHFmcHBQTVFQa1Rq?=
 =?utf-8?B?OXQrSHNUdnY4aWhjN3QyeDQ2OERXbXRldm5iempzeWtXZlo4Qy9WRlFWcS9R?=
 =?utf-8?B?TnNSR2VOUnBEcDBzVUdFcFFzTVV0N25INTJPVVVmL2FXanRMSjJBYnNtdjRv?=
 =?utf-8?Q?SgHd5502g41kENUZ6ZTAlHsh3?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 2738a781-1050-4c33-79f3-08dbe9e471bb
X-MS-Exchange-CrossTenant-AuthSource: PH7PR11MB5984.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2023 16:19:17.4627
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: qkXNoJDgXXrcZxyXHAfbQln6NDE/0NXALwlb2qBPrJp4HoCXKW22hU7n3skaW5YNgazXigwz31QoryLIz7c0uQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4917
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Mon, 20 Nov 2023 08:19:47 -0800 (PST)


On 11/20/23 08:46, Rafael J. Wysocki wrote:
> On Tue, Nov 14, 2023 at 7:09 PM Sam Edwards <cfsworks@gmail.com> wrote:
>>
>> On 11/13/23 16:08, Linus Walleij wrote:
>>> After commit a103f46633fd the kernel stopped compiling for
>>> several ARM32 platforms that I am building with a bare metal
>>> compiler. Bare metal compilers (arm-none-eabi-) don't
>>> define __linux__.
>>
>> Hi Linus,
>>
>> I saw the same baremetal-compiler error here on the ARM64 side of the
>> fence, and narrowed the problem to the same commit as you.
>>
>>>
>>> This is because the header <acpi/platform/acenv.h> is now
>>> in the include path for <linux/irq.h>:
>>
>> More generally, I think it's because of this addition to linux/acpi.h:
>> +#include <linux/fw_table.h>
>>
>> linux/acpi.h is supposed to ensure _LINUX is defined (if it isn't
>> already done by a non-baremetal compiler) before we start pulling in
>> ACPICA includes, so that ACPICA knows the platform. But because
>> fw_table.h contains:
>> #include <linux/acpi.h>
>> #include <acpi/acpi.h>
>>
>> ...the circular include does nothing (linux/acpi.h's include guard stops
>> the include before _LINUX is defined) and we end up pulling in
>> acpi/acpi.h before we're ready.

Not including either causes compile errors for me. And directly including acpi/acpi.h w/o linux/acpi.h causes triggering the #error and some other stuff:

./include/acpi/platform/aclinux.h:18:2: error: #error "Please don't include <acpi/acpi.h> directly, include <linux/acpi.h> instead."
   18 | #error "Please don't include <acpi/acpi.h> directly, include <linux/acpi.h> instead."
      |  ^~~~~


Only including linux/acpi.h:
In file included from ./include/linux/acpi.h:18,
                 from init/main.c:30:
./include/linux/fw_table.h:32:37: error: field ‘common’ has incomplete type
   32 |         struct acpi_subtable_header common;
      |                                     ^~~~~~
./include/linux/fw_table.h:33:36: error: field ‘hmat’ has incomplete type
   33 |         struct acpi_hmat_structure hmat;
      |                                    ^~~~
./include/linux/fw_table.h:34:40: error: field ‘prmt’ has incomplete type
   34 |         struct acpi_prmt_module_header prmt;
      |                                        ^~~~
./include/linux/fw_table.h:35:33: error: field ‘cedt’ has incomplete type
   35 |         struct acpi_cedt_header cedt;
      |                                 ^~~~


> 
> Yes, that's the problem AFAICS.  Dave?
> 
> What about moving the fw_table.h include in linux/acpi.h below the
> mutex.h one, along with the EXPORT_SYMBOL_ACPI_LIB-related
> definitions?

This builds cleanly for me.

> 
> BTW, I'm not really sure why fw_table.h needs to include both
> linux/acpi.h and acpi/acpi.h, because it should get the latter through
> the former anyway.
> 
>>>
>>>    CC      arch/arm/kernel/irq.o
>>>    CC      kernel/sysctl.o
>>>    CC      crypto/api.o
>>> In file included from ../include/acpi/acpi.h:22,
>>>                   from ../include/linux/fw_table.h:29,
>>>                   from ../include/linux/acpi.h:18,
>>>                   from ../include/linux/irqchip.h:14,
>>>                   from ../arch/arm/kernel/irq.c:25:
>>> ../include/acpi/platform/acenv.h:218:2: error: #error Unknown target environment
>>>    218 | #error Unknown target environment
>>>        |  ^~~~~
>>>
>>> One solution to make compilation with a bare metal compiler
>>> work again is to say the file is used with Linux from within
>>> the kernel if __KERNEL__ is defined so I did that.
>>
>> I am not an ACPI subsystem maintainer, but my understanding is that the
>> files in include/acpi/ are copied verbatim from ACPICA, so any change to
>> those files will have to be sent to the ACPICA project and wouldn't be
>> accepted here.
> 
> There are exceptions, but generally you are right.
> 
>> More likely, we'd want to do something about the circular-include
>> situation between linux/fw_table.h<->linux/acpi.h. That may have further
>> consequences down the road than just our problem here. Perhaps just
>> dropping both #includes from fw_table.h, and lowering the fw_table.h
>> include from within linux/acpi.h to be below <acpi/acpi.h>, is the way
>> to go?
> 
> Something like that.