[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Y6RO29H8AmnswBN7@sirena.org.uk>
Date: Thu, 22 Dec 2022 12:34:35 +0000
From: Mark Brown <broonie@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: James Morse <james.morse@....com>,
Alexandru Elisei <alexandru.elisei@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Oliver Upton <oliver.upton@...ux.dev>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
kvmarm@...ts.cs.columbia.edu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] KVM: arm64: Remove use of ARM64_FEATURE_MASK()
On Thu, Dec 22, 2022 at 12:23:49PM +0000, Marc Zyngier wrote:
> Mark Brown <broonie@...nel.org> wrote:
> > the users to directly use the generated mask macros, writing
> >
> > #define ARM64_FEATURE_MASK(x) (x##_MASK)
> >
> > obviously looks redundant and if we look at the users updating them turns
> If the two are strictly equivalent, then let's use the former as it
> results in a tiny diff.
They are. I'm tempted to move the define to a KVM header to discourage
new use.
> Constantly repainting these files causes no end of conflicts when
> rebasing large series (pKVM, NV...), and makes backporting of fixes
> much harder than it should be. Specially considering that there is a
> single occcurence of an ID register with non-4bit fields.
> Just put a FIXME in the various files so that people do the repainting
> as they change this code.
OK. It does result in the half transitioned files looking really messy
which for the main arm64 code I'd expect to generate complaints but like
you say the conversions have their disadvantages too so if you're OK
with it.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists