On 28/08/2023 22:35, Will Deacon wrote:
> On Sun, Aug 27, 2023 at 11:11:16PM +0100, Suzuki K Poulose wrote:
>> On 21/08/2023 12:28, Will Deacon wrote:
>>> 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.
>
> Ah, ok, so the problem with TRBE isn't anything to do with its connections,
> but simply because the pdata is shared?
Correct, thats an issue outside of the ACPI support. With ACPI, the
coresight_get_platform_data() can't cope with the TRBE with missing
companion device, that is fixed by Anshuman's patch in this series.
Also, please could you confirm the plan forward for merging this
(next version of course) ?
Cheers
Suzuki
>
> Will