linux-hardening - Re: [PATCH][next] drm/amd/pm: Avoid multiple -Wflex-array-member-not-at-end warnings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202601151612.79AAC91869@keescook>
Date: Thu, 15 Jan 2026 16:14:34 -0800
From: Kees Cook <kees@...nel.org>
To: Alex Deucher <alexdeucher@...il.com>
Cc: "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
	"Gustavo A. R. Silva" <gustavoars@...nel.org>,
	Kenneth Feng <kenneth.feng@....com>,
	Alex Deucher <alexander.deucher@....com>,
	Christian König <christian.koenig@....com>,
	Xinhui Pan <Xinhui.Pan@....com>, David Airlie <airlied@...il.com>,
	Simona Vetter <simona@...ll.ch>, amd-gfx@...ts.freedesktop.org,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH][next] drm/amd/pm: Avoid multiple
 -Wflex-array-member-not-at-end warnings

On Wed, Aug 13, 2025 at 08:57:58AM -0400, Alex Deucher wrote:
> On Wed, Aug 13, 2025 at 1:12 AM Gustavo A. R. Silva
> <gustavo@...eddedor.com> wrote:
> >
> > Hi!
> >
> > On 22/04/25 23:58, Gustavo A. R. Silva wrote:
> > >
> > >
> > > On 16/04/25 09:04, Alex Deucher wrote:
> > >> Can you resend, I can't seem to find the original emails.
> > >> Additionally, all of the NISLANDS structures are unused in amdgpu, so
> > >> those could be removed.
> >
> > I'm taking a look at this, and it seems that those NISLANDS structs are actually
> > needed in amdgpu code. For instance, `struct si_power_info` contains a member
> > of the type of `struct ni_power_info`, and this latter struct contains a
> > member of the type of `NISLANDS_SMC_STATETABLE`, thus `NISLANDS_SMC_SWSTATE`
> > and `NISLANDS_SMC_HW_PERFORMANCE_LEVEL` are needed, and so on.
> >
> > So, it seems that all those structs should stay. What do you think?
> 
> They are not used for programming the hardware.  They were just
> inherited from radeon.  All of the NI SMC stuff can be dropped.

(Looking through patchwork...)

It's not obvious for me how to drop that stuff. It seems pretty
integral? What's wanted here?

-- 
Kees Cook