linux-kernel - Re: [PATCH] dmaengine: qcom: bam_dma: Fix BAM

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: <Z4DzHs0gtbTPxq2_@linaro.org>
Date: Fri, 10 Jan 2025 11:15:38 +0100
From: Stephan Gerhold <stephan.gerhold@...aro.org>
To: Md Sadre Alam <quic_mdalam@...cinc.com>
Cc: vkoul@...nel.org, ulf.hansson@...aro.org, robin.murphy@....com,
	kees@...nel.org, u.kleine-koenig@...libre.com,
	linux-arm-msm@...r.kernel.org, av2082000@...il.com,
	dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
	djakov@...nel.org, quic_varada@...cinc.com,
	quic_srichara@...cinc.com
Subject: Re: [PATCH] dmaengine: qcom: bam_dma: Fix BAM_RIVISON register
 handling

On Fri, Jan 10, 2025 at 10:44:09AM +0530, Md Sadre Alam wrote:
> This patch fixes a bug introduced in the previous commit where the
> BAM_DESC_CNT_TRSHLD register was conditionally written based on BAM-NDP
> mode. Additionally, it addresses an issue where reading the BAM_REVISION
> register hangs if num-ees is not zero. A check has been added to prevent
> this.
> 
> Cc: stable@...r.kernel.org
> Fixes: 57a7138d0627 ("dmaengine: qcom: bam_dma: Avoid writing unavailable register")
> Reported-by: Georgi Djakov <djakov@...nel.org>
> Link: https://lore.kernel.org/lkml/9ef3daa8-cdb1-49f2-8d19-a72d6210ff3a@kernel.org/
> Signed-off-by: Md Sadre Alam <quic_mdalam@...cinc.com>
> ---
>  drivers/dma/qcom/bam_dma.c | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index c14557efd577..2b88b27f2f91 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -445,11 +445,15 @@ static void bam_reset(struct bam_device *bdev)
>  	writel_relaxed(val, bam_addr(bdev, 0, BAM_CTRL));
>  
>  	/* set descriptor threshold, start with 4 bytes */
> -	if (in_range(bdev->bam_revision, BAM_NDP_REVISION_START,
> -		     BAM_NDP_REVISION_END))
> +	if (!bdev->num_ees && in_range(bdev->bam_revision, BAM_NDP_REVISION_START,
> +				       BAM_NDP_REVISION_END))
>  		writel_relaxed(DEFAULT_CNT_THRSHLD,
>  			       bam_addr(bdev, 0, BAM_DESC_CNT_TRSHLD));
>  
> +	if (bdev->num_ees && !bdev->bam_revision)
> +		writel_relaxed(DEFAULT_CNT_THRSHLD, bam_addr(bdev, 0,
> +							     BAM_DESC_CNT_TRSHLD));
> +
>  	/* Enable default set of h/w workarounds, ie all except BAM_FULL_PIPE */
>  	writel_relaxed(BAM_CNFG_BITS_DEFAULT, bam_addr(bdev, 0, BAM_CNFG_BITS));
>  
> @@ -1006,10 +1010,14 @@ static void bam_apply_new_config(struct bam_chan *bchan,
>  			maxburst = bchan->slave.src_maxburst;
>  		else
>  			maxburst = bchan->slave.dst_maxburst;
> -		if (in_range(bdev->bam_revision, BAM_NDP_REVISION_START,
> -			     BAM_NDP_REVISION_END))
> +		if (!bdev->num_ees && in_range(bdev->bam_revision, BAM_NDP_REVISION_START,
> +					       BAM_NDP_REVISION_END))
>  			writel_relaxed(maxburst,
>  				       bam_addr(bdev, 0, BAM_DESC_CNT_TRSHLD));
> +
> +		if (bdev->num_ees && !bdev->bam_revision)
> +			writel_relaxed(DEFAULT_CNT_THRSHLD, bam_addr(bdev, 0,
> +								     BAM_DESC_CNT_TRSHLD));

I guess you meant writel_relaxed(maxburst, ...) here?

This patch is quite confusing. We shouldn't duplicate the register
writes here just to have different handling for if (bdev->num_ees) and
if (!bdev->num_ees).

Also, num-ees is unrelated to the question if the BAM is BAM-NDP or
BAM-Lite. Typically we specify qcom,num-ees in the device tree for a BAM
if the BAM is either:

 - Controlled remotely (= powered on and initialized outside of Linux)
   This is the case for the SLIMbus BAM Georgi mentioned.

 - Powered remotely (= powered on outside of Linux, but must be
   initialized inside Linux)

Reading BAM_REVISION in these cases will hang in bam_init(), because we
cannot guarantee the BAM is already powered on when the bam_dma driver
is being loaded in Linux. We need to delay reading the register until
the BAM is up.

Given that these writes happen only for the !bdev->controlled_remotely
case, you could fix this more cleanly by reading the BAM revision inside
bam_reset().

Thanks,
Stephan