linux-kernel - Re: [PATCH v4] dmaengine: qcom: bam_dma: Avoid writing unavailable register

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: <Z4D2jQNNW94qGIlv@linaro.org>
Date: Fri, 10 Jan 2025 11:29:33 +0100
From: Stephan Gerhold <stephan.gerhold@...aro.org>
To: Md Sadre Alam <quic_mdalam@...cinc.com>
Cc: vkoul@...nel.org, robin.murphy@....com, u.kleine-koenig@...libre.com,
	martin.petersen@...cle.com, fenghua.yu@...el.com,
	av2082000@...il.com, linux-arm-msm@...r.kernel.org,
	dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
	quic_mmanikan@...cinc.com, quic_srichara@...cinc.com,
	quic_varada@...cinc.com
Subject: Re: [PATCH v4] dmaengine: qcom: bam_dma: Avoid writing unavailable
 register

On Fri, Dec 20, 2024 at 03:12:03PM +0530, Md Sadre Alam wrote:
> Avoid writing unavailable register in BAM-Lite mode.
> BAM_DESC_CNT_TRSHLD register is unavailable in BAM-Lite
> mode. Its only available in BAM-NDP mode. So only write
> this register for clients who is using BAM-NDP.
> 
> Signed-off-by: Md Sadre Alam <quic_mdalam@...cinc.com>

What are we actually fixing here? Which platform is affected? Is there a
crash, reset, or incorrect behavior?

We have had this code for years without reported issues, with both
BAM-NDP and BAM-Lite instances. The register documentation on APQ8016E
documents the BAM_DESC_CNT_TRSHLD register even for the BAM-Lite
instance. There is a comment that it doesn't apply to BAM-Lite, but I
would expect the written value just ends up being ignored in that case.

Also, there is not just BAM-NDP and BAM-Lite, but also plain "BAM". What
about that one? Should we write to BAM_DESC_CNT_TRSHLD?

> ---
> Change in [v4]
> 
> * Added in_range() macro
> 
> Change in [v3]
> 
> * Removed BAM_LITE macro
> 
> * Updated commit message
> 
> * Adjusted if condition check
> 
> * Renamed BAM-NDP macro to BAM_NDP_REVISION_START and
>    BAM_NDP_REVISION_END
> 
> Change in [v2]
> 
> * Replace 0xff with REVISION_MASK in the statement
>    bdev->bam_revision = val & REVISION_MASK
> 
> Change in [v1]
> 
> * Added initial patch
> 
>  drivers/dma/qcom/bam_dma.c | 24 ++++++++++++++++--------
>  1 file changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index bbc3276992bb..c14557efd577 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -59,6 +59,9 @@ struct bam_desc_hw {
>  #define DESC_FLAG_NWD BIT(12)
>  #define DESC_FLAG_CMD BIT(11)
>  
> +#define BAM_NDP_REVISION_START	0x20
> +#define BAM_NDP_REVISION_END	0x27
> +

Are you sure this covers all SoCs we support upstream? If one of the
older or newer supported SoCs uses a value outside of this range, it
will now be missing the register write.

Thanks,
Stephan