[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ee97e1d6-5a21-2c5c-4fdf-05e2700e94cc@intel.com>
Date: Wed, 1 Feb 2023 12:49:22 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "Joseph, Jithu" <jithu.joseph@...el.com>, hdegoede@...hat.com,
markgross@...nel.org
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
gregkh@...uxfoundation.org, rostedt@...dmis.org,
ashok.raj@...el.com, tony.luck@...el.com,
linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
patches@...ts.linux.dev, ravi.v.shankar@...el.com,
thiago.macieira@...el.com, athenas.jimenez.gonzalez@...el.com,
sohil.mehta@...el.com
Subject: Re: [PATCH 4/5] platform/x86/intel/ifs: Implement Array BIST test
On 2/1/23 11:56, Joseph, Jithu wrote:
>> Voila! Less code, less obfuscation, less duplicated effort. Or, worst
> Agreed, will modify it as you suggest above to remove the duplicate zero assignments
... and the union ... and the _unnecessary_ bitfields. You can make an
argument that ->ctrl_result should be a bitfield. The other
structure members, not so much. Make them standalone unsigned integers.
But, when it's down to a single bit in an otherwise completely
unpopulated byte-sized field, your arguments for using a bitfield kinda
dry up. But, heck, if that's the hill you want to die on, who am I to
stop you?
Powered by blists - more mailing lists