linux-kernel - Re: linux-next: manual merge of the coresight tree with the arm-perf, arm64 trees

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] [day] [month] [year] [list]

Message-ID: <20230821113345.GD19469@willie-the-truck>
Date:   Mon, 21 Aug 2023 12:33:45 +0100
From:   Will Deacon <will@...nel.org>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Mathieu Poirier <mathieu.poirier@...aro.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Suzuki K Poulose <suzuki.poulose@....com>
Subject: Re: linux-next: manual merge of the coresight tree with the
 arm-perf, arm64 trees

Hi Stephen,

On Mon, Aug 21, 2023 at 02:40:30PM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the coresight tree got a conflict in:
> 
>   drivers/hwtracing/coresight/coresight-trbe.c
> 
> between commit:
> 
>   e926b8e9eb40 ("coresight: trbe: Add a representative coresight_platform_data for TRBE")
> 
> from the arm-perf, arm64 trees and commit:
> 
>   39744738a67d ("coresight: trbe: Allocate platform data per device")
> 
> from the coresight tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary.
> This is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/hwtracing/coresight/coresight-trbe.c
> index 9c59e2652b20,e20c1c6acc73..000000000000
> --- a/drivers/hwtracing/coresight/coresight-trbe.c
> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
> @@@ -1244,6 -1254,10 +1254,21 @@@ static void arm_trbe_register_coresight
>   	if (!desc.name)
>   		goto cpu_clear;
>   
>  -	desc.pdata = coresight_get_platform_data(dev);
> ++	/*
> ++	 * TRBE coresight devices do not need regular connections
> ++	 * information, as the paths get built between all percpu
> ++	 * source and their respective percpu sink devices. Though
> ++	 * coresight_register() expect device connections via the
> ++	 * platform_data, which TRBE devices do not have. As they
> ++	 * are not real ACPI devices, coresight_get_platform_data()
> ++	 * ends up failing. Instead let's allocate a dummy zeroed
> ++	 * coresight_platform_data structure and assign that back
> ++	 * into the device for that purpose.
> ++	 */
> ++	desc.pdata = devm_kzalloc(dev, sizeof(*desc.pdata), GFP_KERNEL);
> + 	if (IS_ERR(desc.pdata))
> + 		goto cpu_clear;

Although this is what I would've done too, I think there's a deeper
question as to whether the per-device pdata allocation is even needed [1].
So I'll drop the coresight/ changes from my tree(s) while this is worked
out.

Cheers,

Will

[1] https://lore.kernel.org/lkml/20230821112851.GC19469@willie-the-truck/T/#mc78e19ae31612a6b5947b83180ca64fd223c351e