[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230821112851.GC19469@willie-the-truck>
Date: Mon, 21 Aug 2023 12:28:51 +0100
From: Will Deacon <will@...nel.org>
To: Suzuki K Poulose <suzuki.poulose@....com>
Cc: Anshuman Khandual <anshuman.khandual@....com>,
linux-arm-kernel@...ts.infradead.org, catalin.marinas@....com,
kernel-team@...roid.com,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
coresight@...ts.linaro.org, linux-kernel@...r.kernel.org,
James Clark <james.clark@....com>,
Mike Leach <mike.leach@...aro.org>, yangyicong@...wei.com,
Mark Rutland <mark.rutland@....com>,
Sami Mujawar <sami.mujawar@....com>,
Leo Yan <leo.yan@...aro.org>
Subject: Re: [PATCH V5 0/4] coresight: trbe: Enable ACPI based devices
On Sat, Aug 19, 2023 at 08:36:28AM +0100, Suzuki K Poulose wrote:
> On 18/08/2023 19:04, Will Deacon wrote:
> > On Thu, 17 Aug 2023 11:24:01 +0530, Anshuman Khandual wrote:
> > > This series enables detection of ACPI based TRBE devices via a stand alone
> > > purpose built representative platform device. But as a pre-requisite this
> > > changes coresight_platform_data structure assignment for the TRBE device.
> > >
> > > This series is based on v6.5-rc5 kernel, is also dependent on the following
> > > EDK2 changes posted earlier by Sami.
> > >
> > > [...]
> >
> > Applied to will (for-next/perf), thanks!
> >
> > [1/4] arm_pmu: acpi: Refactor arm_spe_acpi_register_device()
> > https://git.kernel.org/will/c/81e5ee471609
> > [2/4] arm_pmu: acpi: Add a representative platform device for TRBE
> > https://git.kernel.org/will/c/1aa3d0274a4a
> > [3/4] coresight: trbe: Add a representative coresight_platform_data for TRBE
> > https://git.kernel.org/will/c/e926b8e9eb40
>
> This will conflict with what I have (already) sent to Greg for
> coresight/next. Please let me know how you would like handle it
Hmm, the rationale behind your change to make the pdata allocation
per-device in ("coresight: trbe: Allocate platform data per device")
confuses me: with Anshuman's change to allocate the pdata using
devm_kzalloc(), there shouldn't be any connections for the coresight
core to trip over, should there?
It would've been nice to know about the conflict earlier, but since I
think you're away this week and we're likely to hit the merge window
next week, I'm going to drop the coresight patches for now.
Will
Powered by blists - more mailing lists