Re: [PATCH V5 0/4] coresight: trbe: Enable ACPI based devices

[Anshuman Khandual]

On 8/28/23 03:41, Suzuki K Poulose wrote:
> On 21/08/2023 12:28, Will Deacon wrote:
>> 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?
> 
> Anshuman's patch is working around the problem of "TRBE platform
> device with ACPI doesn't have a valid companion device" - this is a problem for the acpi_get_coresight_platform_data(). The work
> around is to move the "allocation" from coresight_get_platform_data()
> to the driver (given we don't need anything else from the ACPI except
> the IRQ). That doesn't change *how* it is allocated.
> Also please note that, the TRBE driver creates a TRBE coresight_device per-CPU and the platform data is shared by all of these devices, which
> the coresight core driver doesn't cope with. The other option is to
> move the releasing of these platform-data to the individual drivers,
> which is quite an invasive change. Or, make the core driver tolerate
> a NULL platform data, which is also again invasive. So the merged fix
> is correct and is still valid after this patch.
> 
>>
>> 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.
> 
> Apologies, I was expecting to queue the changes via coresight tree,
> given how it was affecting the tree and was awaiting your Ack. However
> I didn't confirm it on the list, which is my mistake.
> 
> The other problem was reported and the fix eventually had to
> conflict with Anshuman's series, which he was made aware of.
> Given, your Ack was missing I hoping that Anshuman could respin
> the series with your Ack on top of the fix and eventually queue
> that via my tree.

As Will had picked up the series for arm64 tree, I had assumed that the
conflict fix will be taken care of in the process. Hence did not resend
the series, but it got suddenly dropped.

I am wondering - would it be worth re-spinning the series now fixing the
conflict, does it even have a chance for 6.6-rc1 ? Otherwise, will respin
the series after the merge window is over.