[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<GV1PR08MB105217A184D21CA8FB7C4E6BFFB292@GV1PR08MB10521.eurprd08.prod.outlook.com>
Date: Thu, 28 Nov 2024 06:39:37 +0000
From: Yeo Reum Yun <YeoReum.Yun@....com>
To: James Clark <james.clark@...aro.org>, Suzuki Poulose
<Suzuki.Poulose@....com>, "mike.leach@...aro.org" <mike.leach@...aro.org>
CC: "coresight@...ts.linaro.org" <coresight@...ts.linaro.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-rt-devel@...ts.linux.dev"
<linux-rt-devel@...ts.linux.dev>, nd <nd@....com>,
"alexander.shishkin@...ux.intel.com" <alexander.shishkin@...ux.intel.com>,
"bigeasy@...utronix.de" <bigeasy@...utronix.de>, "clrkwllms@...nel.org"
<clrkwllms@...nel.org>, "rostedt@...dmis.org" <rostedt@...dmis.org>
Subject: Re: [PATCH 2/9] coresight-etm4x: change etmv4_drvdata spinlock type
to raw_spinlock_t
Hi James,
> There's a lot of churn in this function just to use the new scoped
> guard, but there was only one lock and unlock anyway. There are a few
> other cases of this in the whole set.
>
> The scoped guards make it easier to write correct code, but I'm not sure
> we gain anything here other than a bigger diff and more to review by
> changing already working code. Having said that I did review all the
> changes and I'm pretty sure they're all ok, so I'm on the fence about
> whether it's worth going back and undoing all of them.
>
> Surely updating to raw spinlocks is a search and replace to fix a
> specific problem, and the scoped guard stuff can be done on a case by
> case basis when anything is re-written in the future?
>
> I don't know if we're considering a fixes tag, if PREEMPT_RT is 6.12?
> It's probably not necessary but if so we definitely want to minimise the
> change.
At first, thanks to review :) and as you said there's no functional change
except change of locktype.
But I thougt making seperate patchset to change locktype and
apply scoped_guard to two patchset makes people do duplicate review for
the same code and almost same posittion.
Since there's no functional change and reviewed,
I think it doesn't need to seperate..?
Thanks.
Powered by blists - more mailing lists