From: Catalin Marinas <catalin.marinas@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] arm64/fpsimd: Only provide the length to cpufeature for xCR registers
Date: Wed, 9 Aug 2023 17:11:38 +0100 [thread overview]
Message-ID: <ZNO6uh02/XxzhPAX@arm.com> (raw)
In-Reply-To: <02b86e5c-221a-4e03-bdca-c7f7798e2e01@sirena.org.uk>
On Fri, Aug 04, 2023 at 05:37:25PM +0100, Mark Brown wrote:
> On Fri, Aug 04, 2023 at 05:20:21PM +0100, Catalin Marinas wrote:
> > On Thu, Aug 03, 2023 at 06:44:24PM +0100, Mark Brown wrote:
> > > On Thu, Aug 03, 2023 at 05:39:38PM +0100, Catalin Marinas wrote:
> > > > Maybe that's the simplest fix, especially if you want it in stable, but
> > >
> > > Yeah, it's definitely the sort of change we want as a fix - anything
> > > more invasive would be inappropriate.
> >
> > I'd say it's still ok if we can just rip come code out safely (the fake
> > ID reg).
>
> It's the safely bit that concerns me here - it feels like a great way to
> discover why the code was there, possibly including a use that was there
> in the past but has subsequently been removed so bites a stable version.
As discussed earlier, let's queue this patch as is (for 6.6 I'd say)
with cc stable and post a new patch on top that removes the fake CPUID
register going forward, in case we missed anything.
For this patch:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] arm64/fpsimd: Only provide the length to cpufeature for xCR registers
Date: Wed, 9 Aug 2023 17:11:38 +0100 [thread overview]
Message-ID: <ZNO6uh02/XxzhPAX@arm.com> (raw)
In-Reply-To: <02b86e5c-221a-4e03-bdca-c7f7798e2e01@sirena.org.uk>
On Fri, Aug 04, 2023 at 05:37:25PM +0100, Mark Brown wrote:
> On Fri, Aug 04, 2023 at 05:20:21PM +0100, Catalin Marinas wrote:
> > On Thu, Aug 03, 2023 at 06:44:24PM +0100, Mark Brown wrote:
> > > On Thu, Aug 03, 2023 at 05:39:38PM +0100, Catalin Marinas wrote:
> > > > Maybe that's the simplest fix, especially if you want it in stable, but
> > >
> > > Yeah, it's definitely the sort of change we want as a fix - anything
> > > more invasive would be inappropriate.
> >
> > I'd say it's still ok if we can just rip come code out safely (the fake
> > ID reg).
>
> It's the safely bit that concerns me here - it feels like a great way to
> discover why the code was there, possibly including a use that was there
> in the past but has subsequently been removed so bites a stable version.
As discussed earlier, let's queue this patch as is (for 6.6 I'd say)
with cc stable and post a new patch on top that removes the fake CPUID
register going forward, in case we missed anything.
For this patch:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
next prev parent reply other threads:[~2023-08-09 16:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-31 13:58 [PATCH v2] arm64/fpsimd: Only provide the length to cpufeature for xCR registers Mark Brown
2023-07-31 13:58 ` Mark Brown
2023-08-03 16:39 ` Catalin Marinas
2023-08-03 16:39 ` Catalin Marinas
2023-08-03 17:44 ` Mark Brown
2023-08-03 17:44 ` Mark Brown
2023-08-04 16:20 ` Catalin Marinas
2023-08-04 16:20 ` Catalin Marinas
2023-08-04 16:37 ` Mark Brown
2023-08-04 16:37 ` Mark Brown
2023-08-09 16:11 ` Catalin Marinas [this message]
2023-08-09 16:11 ` Catalin Marinas
2023-08-11 11:44 ` Will Deacon
2023-08-11 11:44 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZNO6uh02/XxzhPAX@arm.com \
--to=catalin.marinas@arm.com \
--cc=broonie@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.