Re: git: 07c64d74917e - main - acpica: Import ACPICA 20230628
Date: Wed, 31 Jan 2024 20:43:55 UTC
In message <737703f2-26a6-4a84-a64b-3fa55cad721c@FreeBSD.org>, Andriy Gapon wri tes: > On 31/01/2024 19:40, Cy Schubert wrote: > > In message <04c4a0e1-aa79-4d25-a1f7-2196cfa65578@FreeBSD.org>, Jung-uk Kim > > writ > > es: > >> 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: fiel > d > >>> '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? > > > > Though they incorporated the WOL patch I've been using, they've broken > > poweroff. > > The poweroff issue could be because of 9cdf326b4f Thanks. I clued into that a while ago after taking a break to read the ML. This smelled of the original WOL problem I had last year that required pulling the plug to allow the NIC to see the magic packet, but worse. Hence I was barking up the wrong tree. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0