Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Feb 2024 16:42:55 -0500
From:      Jung-uk Kim <jkim@FreeBSD.org>
To:        Dmitry Salychev <dsl@FreeBSD.org>
Cc:        Baptiste Daroussin <bapt@freebsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org
Subject:   Re: git: 07c64d74917e - main - acpica: Import ACPICA 20230628
Message-ID:  <dfaeaf57-21c2-4051-bf94-9f3a8b536384@FreeBSD.org>
In-Reply-To: <86o7cz99u6.fsf@peasant.tower.home>
References:  <202401310406.40V46B9a000876@gitrepo.freebsd.org> <thik6e6mp53h242l6bhgyxkzl45jne5zhxb7retxgyvot3x6jq@v2yuxtpvczg7> <04c4a0e1-aa79-4d25-a1f7-2196cfa65578@FreeBSD.org> <86o7cz99u6.fsf@peasant.tower.home>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------cjikkbECSwXq41OizwlgXpQS
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 24. 2. 1., Dmitry Salychev wrote:
> 
> Hi,
> 
> Jung-uk Kim <jkim@FreeBSD.org> writes:
> 
>> On 24. 1. 31., Baptiste Daroussin wrote:
>>> Hello,
>>> Either this one or the previous import is breaking arm64 build
>>> --- acpi_iort.o ---
>>> /home/bapt/worktrees/main/sys/arm64/acpica/acpi_iort.c:103:4: error: field
>>> 'data' with variable sized type 'union (unnamed union at
>>> /home/bapt/worktrees/main/sys/arm64/acpica/acpi_iort.c:98:2
>>> )' not at the end of a struct or class is a GNU extension
>>> [-Werror,-Wgnu-variable-sized-type-not-at-end]
>>>     103 |         } data;
>>>           |           ^
>>
>> Sorry for the breakage.  I will fix it soon.
>>
>> BTW, this code was added by this:
>>
>> https://reviews.freebsd.org/D31267
>>
>> It seems struct iort_named_component was a hack, which duplicated
>> ACPI_IORT_NAMED_COMPONENT but with a fixed length field
>> DeviceName[32]. Is it really necessary?
>>
>> Jung-uk Kim
> 
> I'm struggling to understand (a) how the entire anonymous "data" union
> was added by https://reviews.freebsd.org/D31267 as was "named_comp"
> only and (b) what the problem with the "struct iort_named_component" really
> is as ACPI_IORT_ROOT_COMPLEX and ACPI_IORT_SMMU were re-defined as
> incomplete types in the new version of ACPICA. Everything is compilable
> as it used to be with the attached patch.

FYI, ACPICA 20230331 dropped support for ANSI C (C89) and minimum 
requirement is C99 now.  One of the first feature they used was the 
variable-length array, which replaced "foo[1]" hack.  Previously, 
"sizeof(struct bar)" was not real size because of the (fake 
variable-length) array at the end of it.  Now they removed the hack and 
started using real variable-length arrays.  I believe the hack in 
acpi_iort.c was to work around the fake 1-byte array but it does not 
work any more because all ACPI_IORT_* are now using correct VLA.  So, 
the cleanest way to fix this is using ACPI_IORT_NAMED_COMPONENT instead 
of "struct iort_named_component" (see attached PoC patch), which also 
eliminates the need for DeviceName[32].

Jung-uk Kim
--------------cjikkbECSwXq41OizwlgXpQS
Content-Type: text/x-patch; charset=UTF-8; name="iort.diff"
Content-Disposition: attachment; filename="iort.diff"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL3N5cy9hcm02NC9hY3BpY2EvYWNwaV9pb3J0LmMgYi9zeXMvYXJtNjQv
YWNwaWNhL2FjcGlfaW9ydC5jCmluZGV4IGEwZTI0Nzg4Yjc3NS4uMjk4Njc5ZDA1YzdkIDEw
MDY0NAotLS0gYS9zeXMvYXJtNjQvYWNwaWNhL2FjcGlfaW9ydC5jCisrKyBiL3N5cy9hcm02
NC9hY3BpY2EvYWNwaV9pb3J0LmMKQEAgLTc0LDE0ICs3NCw2IEBAIHN0cnVjdCBpb3J0X2l0
c19lbnRyeSB7CiAJaW50CQkJcHhtOwogfTsKIAotc3RydWN0IGlvcnRfbmFtZWRfY29tcG9u
ZW50Ci17Ci0JVUlOVDMyICAgICAgICAgICAgICAgICAgTm9kZUZsYWdzOwotCVVJTlQ2NCAg
ICAgICAgICAgICAgICAgIE1lbW9yeVByb3BlcnRpZXM7Ci0JVUlOVDggICAgICAgICAgICAg
ICAgICAgTWVtb3J5QWRkcmVzc0xpbWl0OwotCWNoYXIgICAgICAgICAgICAgICAgICAgIERl
dmljZU5hbWVbMzJdOyAvKiBQYXRoIG9mIG5hbWVzcGFjZSBvYmplY3QgKi8KLX07Ci0KIC8q
CiAgKiBJT1JUIG5vZGUuIEVhY2ggbm9kZSBoYXMgc29tZSBkZXZpY2Ugc3BlY2lmaWMgZGF0
YSBkZXBlbmRpbmcgb24gdGhlCiAgKiB0eXBlIG9mIHRoZSBub2RlLiBUaGUgbm9kZSBjYW4g
YWxzbyBoYXZlIGEgc2V0IG9mIG1hcHBpbmdzLCBPUiBpbgpAQCAtMTAzLDcgKzk1LDcgQEAg
c3RydWN0IGlvcnRfbm9kZSB7CiAJCUFDUElfSU9SVF9ST09UX0NPTVBMRVgJCXBjaV9yYzsJ
LyogUENJIHJvb3QgY29tcGxleCAqLwogCQlBQ1BJX0lPUlRfU01NVQkJCXNtbXU7CiAJCUFD
UElfSU9SVF9TTU1VX1YzCQlzbW11X3YzOwotCQlzdHJ1Y3QgaW9ydF9uYW1lZF9jb21wb25l
bnQJbmFtZWRfY29tcDsKKwkJQUNQSV9JT1JUX05BTUVEX0NPTVBPTkVOVAluYW1lZF9jb21w
OwogCX0gZGF0YTsKIH07CiAKQEAgLTMyNSw2ICszMTcsNyBAQCBpb3J0X2FkZF9ub2RlcyhB
Q1BJX0lPUlRfTk9ERSAqbm9kZV9lbnRyeSwgdV9pbnQgbm9kZV9vZmZzZXQpCiAJQUNQSV9J
T1JUX1NNTVVfVjMgKnNtbXVfdjM7CiAJQUNQSV9JT1JUX05BTUVEX0NPTVBPTkVOVCAqbmFt
ZWRfY29tcDsKIAlzdHJ1Y3QgaW9ydF9ub2RlICpub2RlOworCXNpemVfdCBuYW1lX2xlbjsK
IAogCW5vZGUgPSBtYWxsb2Moc2l6ZW9mKCpub2RlKSwgTV9ERVZCVUYsIE1fV0FJVE9LIHwg
TV9aRVJPKTsKIAlub2RlLT50eXBlID0gIG5vZGVfZW50cnktPlR5cGU7CkBAIC0zNjAsMTAg
KzM1MywxNCBAQCBpb3J0X2FkZF9ub2RlcyhBQ1BJX0lPUlRfTk9ERSAqbm9kZV9lbnRyeSwg
dV9pbnQgbm9kZV9vZmZzZXQpCiAJCW1lbWNweSgmbm9kZS0+ZGF0YS5uYW1lZF9jb21wLCBu
YW1lZF9jb21wLCBzaXplb2YoKm5hbWVkX2NvbXApKTsKIAogCQkvKiBDb3B5IG5hbWUgb2Yg
dGhlIG5vZGUgc2VwYXJhdGVseS4gKi8KKwkJbmFtZV9sZW4gPSBub2RlX2VudHJ5LT5MZW5n
dGg7CisJCW5hbWVfbGVuIC09IEFDUElfT0ZGU0VUKEFDUElfSU9SVF9OQU1FRF9DT01QT05F
TlQsIERldmljZU5hbWUpOworCQluYW1lX2xlbiA9IHN0cm5sZW4obm9kZS0+ZGF0YS5uYW1l
ZF9jb21wLkRldmljZU5hbWUsIG5hbWVfbGVuKTsKKwkJbmFtZWRfY29tcCA9IHJlYWxsb2Mo
bmFtZWRfY29tcCwgc2l6ZW9mKCpub2RlKSArIG5hbWVfbGVuICsgMSwKKwkJICAgIE1fREVW
QlVGLCBNX1dBSVRPSyB8IE1fWkVSTyk7CiAJCXN0cm5jcHkobm9kZS0+ZGF0YS5uYW1lZF9j
b21wLkRldmljZU5hbWUsCi0JCSAgICBuYW1lZF9jb21wLT5EZXZpY2VOYW1lLAotCQkgICAg
c2l6ZW9mKG5vZGUtPmRhdGEubmFtZWRfY29tcC5EZXZpY2VOYW1lKSk7Ci0JCW5vZGUtPmRh
dGEubmFtZWRfY29tcC5EZXZpY2VOYW1lWzMxXSA9IDA7CisJCSAgICBuYW1lZF9jb21wLT5E
ZXZpY2VOYW1lLCBuYW1lX2xlbiArIDEpOworCQlub2RlLT5kYXRhLm5hbWVkX2NvbXAuRGV2
aWNlTmFtZVtuYW1lX2xlbl0gPSAwOwogCiAJCWlvcnRfY29weV9kYXRhKG5vZGUsIG5vZGVf
ZW50cnkpOwogCQlUQUlMUV9JTlNFUlRfVEFJTCgmbmFtZWRfbm9kZXMsIG5vZGUsIG5leHQp
Owo=

--------------cjikkbECSwXq41OizwlgXpQS--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?dfaeaf57-21c2-4051-bf94-9f3a8b536384>