linux-kernel - Re: [PATCH V3 3/4] coresight: trbe: Add a representative coresight_platform

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 for Android: free password hash cracker in your pocket

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

Message-ID: <3a9b34c0-f5cc-8d55-d5b7-813e400d7715@arm.com>
Date:   Thu, 3 Aug 2023 14:55:13 +0100
From:   Suzuki K Poulose <suzuki.poulose@....com>
To:     Anshuman Khandual <anshuman.khandual@....com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     Sami Mujawar <sami.mujawar@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Mike Leach <mike.leach@...aro.org>,
        Leo Yan <leo.yan@...aro.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        James Clark <james.clark@....com>, coresight@...ts.linaro.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3 3/4] coresight: trbe: Add a representative
 coresight_platform_data for TRBE

On 03/08/2023 06:56, Anshuman Khandual wrote:
> TRBE coresight devices do not need regular connections information, as the
> paths get built between all percpu source and their respective percpu sink
> devices. Please refer 'commit 2cd87a7b293d ("coresight: core: Add support
> for dedicated percpu sinks")' which added support for percpu sink devices.
> 
> coresight_register() expect device connections via the platform_data. TRBE
> devices do not have any graph connections and thus is empty. With upcoming
> ACPI support for TRBE, we do not get a real acpi_device and thus
> coresight_get_platform_dat() will end up in failures. Hence this allocates
> a zeroed coresight_platform_data structure and assigns that back into the
> device.
> 
> Cc: Suzuki K Poulose <suzuki.poulose@....com>
> Cc: Mike Leach <mike.leach@...aro.org>
> Cc: Leo Yan <leo.yan@...aro.org>
> Cc: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
> Cc: coresight@...ts.linaro.org
> Cc: linux-arm-kernel@...ts.infradead.org
> Cc: linux-kernel@...r.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
> ---
>   drivers/hwtracing/coresight/coresight-trbe.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
> index 7720619909d6..e1d9d06e7725 100644
> --- a/drivers/hwtracing/coresight/coresight-trbe.c
> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
> @@ -1494,9 +1494,9 @@ static int arm_trbe_device_probe(struct platform_device *pdev)
>   	if (!drvdata)
>   		return -ENOMEM;
>   
> -	pdata = coresight_get_platform_data(dev);
> -	if (IS_ERR(pdata))
> -		return PTR_ERR(pdata);
> +	pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> +	if (!pdata)
> +		return -ENOMEM;

Please could you add a comment in here, on why we use a dummy platform
data ? It is good to have documented it in the code too.

Suzuki


>   
>   	dev_set_drvdata(dev, drvdata);
>   	dev->platform_data = pdata;