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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <31db1d51-68f0-59cf-527c-5aebef1663c2@arm.com>
Date:   Mon, 28 Aug 2023 07:47:31 +0530
From:   Anshuman Khandual <anshuman.khandual@....com>
To:     Suzuki K Poulose <suzuki.poulose@....com>,
        Will Deacon <will@...nel.org>
Cc:     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 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.